hvip MCP Server

Server Quality Checklist

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

Latest release: v0.6.1
Disambiguation1/5
There are many tools with nearly identical names and descriptions (e.g., okx_get_ticker vs okx_get_tickers, multiple candles variants) that lack sufficient disambiguation for an agent. The consistent instruction to call agent_catalog first acknowledges this ambiguity.
Naming Consistency2/5
While okx_ tools mostly follow a verb_noun pattern, the mix of prefixes (okx_, agent_, outcomes_, xlayer_, codegraph_) and occasional anomalous names (e.g., okx_preset_account_switch) create inconsistency. Naming within the predictions domain is particularly messy with overlapping okx_predictions_ and outcomes_ prefixes.
Tool Count1/5
373 tools is far beyond reasonable for an MCP server. Even for a comprehensive exchange API, this count overwhelms agents and suggests a low-level API mapping rather than a curated, agent-friendly interface. The extreme size makes navigation impractical without the agent_catalog crutch.
Completeness4/5
The tool set covers an extensive range of exchange operations: market data, trading, account management, funding, staking, predictions, spreads, copy trading, subaccounts, and more. It also includes agent orchestration and code intelligence tools, making it broadly comprehensive for the OKX ecosystem.
Average 2.3/5 across 347 of 373 tools scored. Lowest: 1.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 148 commits in the last 12 weeks
- Last stable release on June 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 are provided, so the description carries full burden for behavioral disclosure. It does not mention that this is a write operation, what it cancels (all orders? specific types?), any side effects, or required permissions. The description is insufficient for an agent to understand 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.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to convey essential information. It is under-specified rather than concise. Every sentence should earn its place, but here the only substantive instruction ('请先调用 agent_catalog') does not explain the tool itself.
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 2 parameters, no output schema, no annotations, and a nearly useless description, the tool is incomplete. The agent cannot determine what the tool returns, what constitutes a successful call, or how to interpret results. This is far from adequate.
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 100% (both parameters have descriptions in the schema), so the schema provides basic parameter meaning. However, the description adds no extra context about how parameters affect the mass cancellation. The baseline is 3 for high coverage, but the description contributes nothing, so a 2 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description fails to state what the tool does. It contains tags like '[L:WRITE]' and a Chinese instruction to call agent_catalog first, but no verb or resource indicating the tool's action. The tool name 'okx_mass_cancel' suggests mass cancellation of orders, but the description does not confirm this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The only instruction is to call agent_catalog first, which is a prerequisite but does not help the agent decide when to invoke this tool over other order-canceling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It includes '[L:READ]' hinting at read-only but not explicitly. No mention of authentication, side effects, rate limits, or pagination. The description fails to provide meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not helpful; it contains cryptic codes and a cross-reference without substance. It wastes space without conveying actionable information, failing the conciseness goal.
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, the description should explain return values or behavior. It does not. The tool context (event fills) suggests a specific data type, but the description is wholly incomplete for an agent to invoke or understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (limit, instId) having Chinese descriptions. The tool description does not add any additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[预测] | → 请先调用 agent_catalog'. It does not state what the tool does (e.g., retrieve fills for event trades). The purpose is unclear, and the tool name 'okx_event_fills' alone is insufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like okx_get_fills or okx_get_fills_history. The note '→ 请先调用 agent_catalog' suggests a prerequisite but is vague and does not clarify decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only includes a vague '[L:READ]' tag but does not explain any behavioral traits, such as whether it reads account data, requires authentication, or has 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.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is not concisely informative—it is cryptic and incomplete, containing a prerequisite instruction rather than a clear explanation of the tool.
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 likely complexity of retrieving position risk and the absence of an output schema or annotations, the description is extremely incomplete. It fails to describe the return format, risk metrics, or any context needed for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds no meaning beyond the empty schema, but the baseline for zero parameters is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[账户] | → 请先调用 agent_catalog'. It does not clearly state that the tool retrieves account position risk. Instead, it instructs the user to call another tool first, obscuring the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like okx_get_positions or okx_get_balance. The only instruction is to call agent_catalog first, which is a prerequisite, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral disclosure. It does not indicate whether this tool is read-only, destructive, or has specific side effects, quotas, or security implications.
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, but it is under-specification rather than genuine conciseness. It lacks essential information and is not structured effectively to aid an AI agent.
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 tool with 4 required parameters, no output schema, and no annotations, the description provides almost no context. It directs users to call agent_catalog, but fails to explain the tool's functionality, return values, or use cases. This is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description in the schema. However, the tool description itself adds no additional meaning or context beyond what the schema already provides. Baseline score of 3 applies as the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is merely '[L:READ] CAT:[公共] | → 请先调用 agent_catalog', which does not state the tool's purpose. The name suggests converting contract coin, but no explicit verb or resource is provided, and it fails to distinguish from sibling convert tools like okx_convert_trade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The instruction to call agent_catalog first is a prerequisite, not a usage guideline. There is no mention of scenarios, exclusions, or relationships to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description does not disclose any behavioral traits (e.g., return format, side effects, or authorization needs). The '[L:READ]' tag hints at a read operation but no further detail.
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 brief but cryptic and incomplete. It is not effectively concise; it sacrifices clarity 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?
Without output schema or annotations, the description fails to explain what the tool returns or how to use it. The directive to call agent_catalog is insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds no extra meaning to the parameters; it does not mention instType or uly beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lacks any verb or resource statement. It only contains cryptic labels like '[L:READ]' and 'CAT:[公共]' and a directive to call agent_catalog, but does not say what the tool does or what an insurance fund is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The only note is to call agent_catalog first, which is a prerequisite, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only indicates it is a write operation and requires a prerequisite call, but no details about what gets modified, permissions needed, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but at the cost of missing critical information. It is more under-specified than efficiently concise, as it fails to explain the tool's purpose or 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 no output schema and the tool's apparent complexity (moving positions), the description is completely inadequate. It omits return values, behavior, and any actionable guidance beyond a prerequisite call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'body' parameter, but the description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate as the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:WRITE] CAT:[账户] | → 请先调用 agent_catalog' does not state what the tool does. It only tags it as a write operation and references a category, but no verb or resource is described. The tool name implies moving positions, but the description fails to clarify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The instruction to call 'agent_catalog' first is ambiguous and does not explain when to use this tool versus alternatives like other position-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that the tool creates a staking purchase, requires permission, or any side effects. It is essentially empty of behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), but this is under-specification rather than conciseness. It fails to provide necessary information, making it ineffective.
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 is an action (purchase staking) with one required parameter and no output schema or annotations, the description should at least clarify the operation. It is severely incomplete, offering no useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter ('amt') already described as '质押数量（SOL）。必填'. The tool description adds no additional meaning beyond this, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only contains a Chinese instruction '请先调用 agent_catalog' (please call agent_catalog first) and a category marker. The tool name suggests purchasing SOL staking, but the description fails to confirm or describe the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like okx_stake_eth or okx_redeem_sol_staking. The only instruction is to call agent_catalog first, which is a prerequisite but 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.
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 (e.g., side effects, success/failure outcomes, modifications). The description only references another 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 extremely short but lacks substantive information. It is under-specified rather than efficiently concise.
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 lack of output schema and annotations, the description should compensate but fails to provide any meaningful context about tool behavior, return values, or prerequisites beyond a vague reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 100% of parameters with descriptions in Chinese. The tool description adds nothing 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.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only instructs to call another tool first. The purpose is unclear and the tool name alone is insufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Only a prerequisite instruction is given, which does not clarify the tool's own usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions a prerequisite call, not what the tool does, whether it is destructive, requires authentication, or has 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?
Extremely short but not concise in a helpful way. It is cryptic and fails to communicate tool function, thus does not earn its place.
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 modifies account settings, lacks output schema, and has no annotations, the description is completely inadequate. No mention of return values, side effects, or prerequisites beyond the vague agent_catalog call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for posMode. The tool description adds no semantic value 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.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:ADMIN] CAT:[账户] | → 请先调用 agent_catalog' provides metadata and a directive but does not state the tool's purpose. The name implies setting position mode, but the description fails to confirm this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like okx_set_account_mode. The instruction to call agent_catalog first is a prerequisite, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond a misleading '[L:READ]' tag that contradicts the tool's mutating nature (staking). No mention of permissions, side effects, or confirmations.
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 brief but uses cryptic formatting ('[L:READ] CAT:[金融]') that is not informative. It is concise but at the expense of clarity, making it less structured and 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 financial transaction staking ETH, the description is grossly incomplete. It lacks prerequisites, return format, execution details, and fails to leverage the schema or provide any meaningful context 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 100% with clear parameter descriptions (amt and rate). The tool description adds no additional meaning, but the schema already provides sufficient semantic context, so baseline 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a placeholder ('[L:READ] CAT:[金融] | → 请先调用 agent_catalog') that restates the tool name's implication without clarifying the action or resource. It does not state what the tool does, relying solely on the name 'stake_eth' for meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'okx_unstake_eth' or other staking tools. The reference to 'agent_catalog' is a dependency, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only indicates a write operation via the [L:WRITE] tag but provides no details on side effects, required permissions, or what the tool actually does.
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 but lacks essential information. It is under-specified rather than concise.
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 likely performs an action (stop copy trading) and has no output schema, the description fails to explain its purpose, the role of subPosId, or the outcome. Totally inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter subPosId, with a description in the schema. The tool description adds no meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only provides a category tag [L:WRITE] CAT:[策略-跟单] and instructs to call agent_catalog first. The tool name suggests stopping copy trading, but the description fails to confirm or elaborate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like okx_stop_copy_trading. The only hint is to call agent_catalog first, which is a prerequisite, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden but does not disclose any behavioral traits such as authentication requirements, rate limits, or mutability. A withdrawal tool likely has significant behavioral implications (e.g., funds moved, irreversible), but none are mentioned.
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?
Extremely concise but at the expense of essential information. Not effectively structured for agent comprehension.
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 annotations, and description is minimal. For a potentially destructive financial operation, this is critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 6 parameters with 100% coverage, so baseline is 3. Description adds no extra context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is a category label 'FUND_TRANSFER' and a note to call agent_catalog, but does not clearly state that this tool performs withdrawals. Name implies withdrawal, but description fails to confirm the verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. Only a vague instruction to call agent_catalog first, without explaining prerequisites or alternatives.
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 does not disclose any behavioral traits such as data freshness, pagination, or authentication requirements. The description only gives a category and a prerequisite, offering no transparency.
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 but overly cryptic. It lacks clarity and fails to convey essential information. Conciseness is achieved at the expense of usefulness.
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 simplicity (one parameter, no output schema), the description should at least explain what a block ticker is and when to use it. It does not, leaving the agent without sufficient 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?
The description does not add any meaning beyond the input schema. The sole parameter 'instType' is documented in the schema with an enum and description, but the description does not reference or explain it further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not clearly state what the tool does. It provides a category label ('CAT:[行情]') and a prerequisite ('请先调用 agent_catalog'), but the purpose is vague. The name suggests it retrieves block tickers, but the description lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 'okx_get_ticker' or 'okx_get_tickers'. The only instruction is to call 'agent_catalog' first, which is a prerequisite, 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.
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 mentions a prerequisite (calling agent_catalog) but does not describe side effects, authorization needs, or other behaviors.
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 but fails to provide essential information. It is under-speficiation rather than conciseness. The structure is a single line with tags and an instruction.
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 tool that modifies collateral, the description is completely inadequate. It lacks any explanation of the tool's operation, return values, or context. Schema covers params but no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only contains a tag and an instruction to call another tool. The purpose is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The instruction '请先调用 agent_catalog' hints at a prerequisite but does not clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read action ('[L:READ]') but no other behavioral details are provided. Without annotations, this minimal information is insufficient for understanding side effects, permissions, or data characteristics.
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 but lacks structure and fails to front-load the purpose. It is under-specified rather than concise.
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?
Despite having only three parameters and no output schema, the description provides almost no context about the tool's functionality, return values, or behavior, making it inadequate 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 100% and parameters are described in Chinese. The description adds no extra semantic value beyond the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a cryptic status label and instructs to call another tool. The purpose is not conveyed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The instruction to call agent_catalog first is vague and does not clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It includes a '[L:READ]' tag implying read-only, but provides no further details about what data is returned, limitations, or side effects. The prerequisite is vague and doesn't help understand behavior.
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 but at the cost of substance. It is not helpful for an agent to select or invoke the tool correctly. True conciseness would preserve essential information without verbosity.
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 large number of sibling tools, the description fails to differentiate this tool. It does not explain what history trades are, how they differ from other trade endpoints, or provide any usage context. No output schema further limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the two parameters (instId, limit) with descriptions. The description adds nothing beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description fails to state what the tool does. It only provides a category label and a prerequisite ('请先调用 agent_catalog'), leaving the actual purpose unclear. This is a tautology of the name combined with an instruction, not a description of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 like okx_get_trades or okx_get_history_candles. The description only instructs to call agent_catalog first, which is a prerequisite, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral information beyond an ambiguous '[L:READ]' tag. There is no disclosure of effects, permissions, or data characteristics for this 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one line) but fails to convey essential purpose and usage information. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no description of what data is returned, the tool is severely underspecified. For a staking history query, details like date range, status, or response fields are 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% for the single parameter 'limit', described in the schema as '返回条数，默认100'. The description adds no additional meaning, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only contains a tag and an instruction to call agent_catalog, which is unhelpful. The tool name suggests retrieving SOL staking history, but the description fails to confirm this.
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 siblings like okx_get_sol_staking_balance or okx_get_staking_offers. The description lacks 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. The description does not disclose any behavioral traits such as read-only nature, side effects, or required permissions. '[L:READ]' hints at read-only but lacks certainty.
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 (one line), but it is not efficiently informative. It is an under-specification, not concise clarity. Every word does not earn its place.
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 rich ecosystem of OKX staking tools and no output schema, the description is completely inadequate. It does not explain what 'active orders' are, what the tool retrieves, or 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?
The input schema has zero parameters, so schema coverage is 100% vacuously. The description adds no parameter-level meaning, but there is nothing missing. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description fails to state what the tool does. It contains metadata tags '[L:READ]' and 'CAT:[金融]' but no verb or resource. The directive '→ 请先调用 agent_catalog' suggests a prerequisite, not a purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or how it differs from siblings like 'okx_get_staking_offers' or 'okx_get_staking_orders'. The instruction to call agent_catalog first is vague and not an alternative.
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 includes a '[L:READ]' tag indicating a read-only operation, but provides no other behavioral details such as rate limits, required permissions, or data freshness. Since no annotations are present, the description should carry more weight but fails to do so.
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 but lacks substance; it is under-specified rather than concise. Every sentence should earn its place, but the existing text does not provide value to the agent.
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 lack of output schema and the large number of sibling tools, the description should clarify return values and differentiate from similar tools. It fails to do so, making the tool insufficiently described for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'instId' is well-described in the schema (including examples and batch query support). The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not clarify what the tool does; it only contains a category tag '行情' and a note to call agent_catalog first, which is misleading. The tool's name implies getting a ticker, but the description fails to explicitly state that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like okx_get_tickers. The instruction to call agent_catalog first is not useful usage guidance and adds confusion.
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 behavioral details. It hints at a write operation via "L:WRITE" but does not explain side effects, permission requirements, or what changes occur. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but incomplete and uninformative. It is under-specified rather than concise, providing no useful information for selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutating operation (set leverage) with potential risks, yet the description omits crucial context like required prerequisites beyond a generic reference, risk warnings, or relation to other tools. Without annotations or output schema, the description is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions and enums for all parameters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only contains a cryptic label "L:WRITE" and a prerequisite to call another tool. The name suggests setting leverage, but the description fails to confirm or detail the 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?
No guidance on when to use this tool versus alternatives. The only hint is a prerequisite ('请先调用 agent_catalog'), but no context about 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description only has a label indicating write operation but does not mention authentication needs, destructive nature, rate limits, error conditions, or other important behaviors. This is severely lacking.
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 but at the expense of utility. It is not concise in a helpful sense; it is under-specified and missing critical information. A useful description would be longer but still concise.
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 (write operation, batch processing, JSON parameter, no output schema), the description is completely inadequate. It does not explain return values, error handling, or any success/failure indicators. The agent would be left guessing about 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 single parameter 'orders' has a detailed description in the schema, including an example and maximum count. The description itself does not add extra semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is vague: only contains a label '[L:WRITE]' and a note to call agent_catalog first. It does not explicitly state that this tool amends batch orders. The parameter description in the schema hints at the purpose, but the description itself is insufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like okx_amend_order (single amend) or okx_batch_cancel_orders. The description does not mention any 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits (e.g., whether it partially updates or replaces, required order state, error conditions). It only states 'L:WRITE' which is minimal. No details about side effects, idempotency, or restrictions are provided.
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 but cryptic. It fails to front-load useful information and the structure is poor, with an unexplainable instruction to call agent_catalog. Conciseness without completeness is not valuable.
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 amending a trading order (4 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain the update semantics, prerequisites, or potential errors, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions in Chinese (e.g., 'new order price', 'order ID'). The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description relies on the name 'amend_order' to imply purpose, but the text '[L:WRITE] CAT:[交易]' only vaguely indicates it's a write operation in trading. It does not explicitly state that it modifies an existing order's price or quantity, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like okx_amend_batch_orders or okx_cancel_order combined with okx_place_order. The instruction '请先调用 agent_catalog' is cryptic and does not clarify the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not explain the impact of amending the ratio, required permissions, reversibility, or any side effects. The label '[L:WRITE]' is redundant given the tool name 'amend'. This is a severe gap.
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 but cryptic and not self-contained. It front-loads labels that are not universally understandable. While concise in word count, it sacrifices clarity and usefulness.
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 role in copy trading profit sharing and the lack of output schema, the description is completely inadequate. It does not explain what the tool achieves, what the agent should expect after calling it, or how it integrates with the suggested prerequisite agent_catalog.
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 100% with one required parameter 'profitSharingRatio' described as '分成比例。必填'. The tool description adds no additional meaning beyond the schema—no format, range, or examples. It fails to enhance agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague and does not clearly state what the tool does beyond 'amend profit sharing ratio'. The label '[L:WRITE]' and category 'CAT:[策略-跟单]' provide hints but lack clarity. It fails to distinguish itself from sibling tools like okx_get_profit_sharing_details or okx_get_copy_settings.
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 guidance is '请先调用 agent_catalog', which indicates a prerequisite but does not explain when to use this tool versus alternatives, scenarios, or exclusions. No context on use cases 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 provided, the description must disclose behavioral traits. It fails to mention that the tool submits multiple orders, any side effects, required permissions, or rate limits. The cryptic label does not convey meaningful behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the expense of clarity. It is under-specified and does not explain the tool's purpose, making it not appropriately sized for the complexity of a batch order tool.
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 (batch orders), the description is severely lacking. It omits return values, error handling, and operational context, making it incomplete for an AI agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter 'orders', including format and max count. The description adds no value 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:WRITE] CAT:[交易] | → 请先调用 agent_catalog' is cryptic and does not clearly state that this tool places multiple orders. It hints at a write operation and a category, but fails to specify the primary function of batch order placement, making it hard to distinguish from sibling tools like okx_place_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as okx_place_order or okx_batch_cancel_orders. The only directive is to call agent_catalog first, which is a prerequisite step but does not help with tool 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 are provided. The description only includes a generic write tag '[L:WRITE]' and a category tag, missing important behavioral details such as idempotency, side effects, required permissions, or error conditions. The description does not add value beyond the tags.
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 but not effectively structured. It uses cryptic abbreviations and non-English tags that hinder clarity. It is not front-loaded with the tool's purpose and fails to earn its place.
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 (two parameters, no output schema), the description is critically incomplete. It lacks information about return values, cancellation constraints, or any context that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with both 'algoId' and 'instId' having descriptions (but these are in Chinese and not in the description). The description adds no additional meaning to the parameters, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:WRITE]' and 'CAT:[交易-委托]', which do not clearly state the tool's purpose. The tool name 'okx_cancel_algo_order' combined with input schema (algoId, instId) hints at cancellation, but the description fails to explicitly state that the tool cancels an algorithm order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention conditions, prerequisites, or context for use. The phrase '→ 请先调用 agent_catalog' (Please call agent_catalog first) is a vague instruction without explanation.
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 does not disclose behavioral traits such as whether the operation is destructive, idempotent, or requires prior steps. The 'WRITE' tag only hints at 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?
Extremely short but omits essential information. It is under-specified, not genuinely concise.
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 fails to provide enough context for a write tool with 3 parameters and no output schema. No return value, prerequisites, or error handling is mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with brief parameter descriptions. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like 'L:WRITE' and 'CAT:[策略-RFQ]' but does not explicitly state that the tool creates a quote for an RFQ. The purpose is implied but not clear, scoring low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like okx_execute_quote or okx_create_rfq. The only hint is to call agent_catalog first, but no context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only contains metadata tags and a prerequisite hint, with no disclosure of side effects, authentication needs, rate limits, or any behavioral traits. This is completely inadequate.
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, but conciseness should not sacrifice clarity. It lacks substantive information and reads as a fragment. Every part is cryptic (tags, Chinese text), and it does not earn its place in helping an agent understand the tool.
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 a cryptic description, the tool is completely unexplained. An agent cannot determine what interest limits are, how they are returned, or any contextual details. This is insufficient for a tool with zero parameters.
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 tool has zero parameters and 100% schema coverage, so the baseline is 4. However, the description adds no meaning beyond the empty schema. It fails to explain what the tool returns or its purpose, which the schema cannot convey. Thus, the description provides minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description contains a tag L:READ and CAT:[账户] hinting at a read operation on account data, but it does not explicitly state what the tool does. The name 'okx_get_interest_limits' suggests retrieving interest limits, but the description lacks a clear verb and resource explanation, making it 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?
The description says '→ 请先调用 agent_catalog' (call agent_catalog first), providing a prerequisite but no context on when to use this tool over alternatives or when not to use it. Sibling tools include many OKX account tools, but no differentiation is provided.
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 does not disclose behavioral traits such as output format, pagination, or data scope. The [L:READ] tag is cryptic and 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but at the expense of clarity. It is under-specified, making it difficult for an agent to understand the tool's function.
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 simple single-parameter schema and no output schema, the description fails to explain the return value or how to use the tool. The note to call agent_catalog first suggests it may not be a standalone tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description in the schema is adequate. The tool description does not add any additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a tag [L:READ] and category [统计] but does not explicitly state what the tool does. The name suggests historical margin lending ratio, but the description lacks a clear verb+resource description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The phrase '请先调用 agent_catalog' is a prerequisite but does not differentiate from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behaviors. It only indicates read-only via '[L:READ]' but lacks details on authentication, rate limits, or side effects. The instruction '请先调用 agent_catalog' is not a 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short, but at the expense of completeness. A single line that does not effectively convey the tool's function. It is under-specified rather than concise.
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?
Missing output schema means the description should compensate by explaining return values, but it does not. The tool's purpose is unclear, and no context differentiates it from similar candle tools. Completely inadequate for a tool with 5 parameters and many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described in the input schema. The tool description adds no additional meaning beyond what the schema already provides, earning the baseline score.
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 only provides a category label '[L:READ] CAT:[行情]' and an instruction to call agent_catalog. It does not state that this tool retrieves mark price candles, leaving the actual purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many sibling candle tools (e.g., okx_get_candles, okx_get_history_candles). The description does not differentiate it or provide any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only includes a cryptic label 'L:READ' without explaining behavioral traits such as side effects, permissions, or rate limits. The agent is left without essential context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but also uninformative and cryptic. Conciseness alone does not justify a higher score because the content is not useful for an agent to understand the tool.
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 large number of sibling tools, lack of output schema, and absence of annotations, the description is severely incomplete. It fails to provide any information about return values, error handling, or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the two required parameters (instId and clOrdId) with Chinese descriptions. The tool description adds no additional meaning beyond what the schema provides. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[交易] | → 请先调用 agent_catalog' is cryptic and does not clearly state the tool's function. The name suggests retrieving an order by client order ID, but the description fails to explicitly state this, making it difficult for an agent to understand 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling list includes many order-related tools (e.g., okx_get_order, okx_get_orders_pending), and the description provides no differentiation or 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 are provided, and the description only includes a generic READ label and category. It does not disclose rate limits, authentication requirements, data scope, or any behavioral traits. The tool's behavior remains 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 extremely short but lacks substantive content. It front-loads 'READ' and 'CAT', but these are not official annotations. The instruction to call agent_catalog is cryptic. Conciseness is achieved at the cost of 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?
Given the absence of an output schema, the description should explain what tickers are returned (e.g., latest prices, volumes). It does not. The tool is part of a large sibling group, yet no context is provided about its specific role or relation to other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'instType' already has a clear description ('产品类型') and enum. The description adds no additional semantic meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the tool as READ and market data (CAT:[行情]), but does not explicitly state that it retrieves multiple tickers for a given instrument type. The instruction '请先调用 agent_catalog' is vague and does not clarify the tool's function. Sibling 'okx_get_ticker' suggests singular vs plural, but the description fails to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'okx_get_ticker' or other market data tools. The only hint is to call 'agent_catalog' first, but there is no explanation of selection criteria or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits. It does not mention whether the tool is read-only, destructive, or what side effects it has. The '[L:READ]' prefix hints at readonly but is not part of the description and is ambiguous.
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 but lacks substance. While it is front-loaded with '[L:READ]' and category, the critical purpose and usage details are missing. Conciseness should not sacrifice completeness; here it results in an under-specified tool.
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 role as an order precheck among many trading tools, the description is severely incomplete. It provides no information about return values, required permissions, or how the precheck result is used. With no output schema, the agent is left guessing 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 100% for the single 'params' parameter. The description adds no extra meaning beyond the schema's description of '订单参数JSON字符串' (order parameters JSON string). Baseline 3 is appropriate since the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[交易] | → 请先调用 agent_catalog'. It suggests a read operation (L:READ) and a trade category, but does not clearly state that the tool pre-checks an order. The purpose is unclear and requires additional context from 'agent_catalog'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The only instruction is to call 'agent_catalog' first, but no explanation of why or what that provides. Sibling tools like 'okx_place_order' or 'okx_preflight_check' likely overlap in functionality, but no differentiation is provided.
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 does not disclose behavioral traits such as side effects, permissions, or rate limits. The tag '[L:READ]' is present but unexplained; it may indicate read-only, but mutation is implied by 'redeem'.
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?
Extremely concise but under-specified. The single line contains tags and a reference to agent_catalog, but lacks substantive content. Conciseness is not valuable without completeness.
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 annotations and output schema, the description should compensate but does not. The tool's relationship to SFP products, prerequisites, and expected behavior are entirely 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 description coverage is 100% (both parameters have descriptions in the schema), so baseline is 3. The description adds no additional semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only includes tags and an instruction to call agent_catalog. It does not explicitly state what the tool does (redeem SFP product). The verb 'redeem' is implied by the tool name, but the description lacks clarity on what 'SFP' is or what redemption entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like okx_get_sfp_products or okx_get_sfp_order_history. The only hint is to call agent_catalog first, but no context on why or what that provides.
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?
The description lacks any behavioral details. The '[L:READ]' tag is ambiguous and likely contradicts the redeeming action (which is a write operation). No permissions, effects, or return values are mentioned. With no annotations, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line with tags and a reference), but this brevity comes at the cost of informativeness. It is under-specified rather than concise.
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 tool that redeems staked SOL, the description gives no context about the redemption process, prerequisites, or outcome. It is incomplete and relies on another tool (agent_catalog) for any meaningful information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter 'amt' with schema coverage 100%. The schema already provides a description (Chinese for redemption amount). The tool description does not add any extra meaning, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a label '[L:READ]' and a category tag, but does not directly state that the tool redeems SOL staking. The name implies the action, but the description is too vague to confirm the purpose. It refers to agent_catalog instead of defining its own function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like okx_purchase_sol_staking or okx_get_sol_staking_balance. The instruction to call agent_catalog first is not a usage guideline but a dependency note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It merely labels the tool as 'WRITE' but gives no details on side effects, permissions, rate limits, or outcomes. The agent learns nothing about what happens when the tool is invoked beyond the obvious mutation implied by 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but its brevity comes at the cost of informativeness. It front-loads a category label but then wastes space on a prerequisite instruction that could be in a separate field. Every sentence should add value; here, the only substantive content is a note about another tool.
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 2 parameters and no output schema or annotations, the description should provide complete context for usage. It fails to explain the tool's return value, error conditions, or how it relates to the prerequisite tool. The description is incomplete and leaves the agent with significant gaps in 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 100% with clear parameter descriptions in the schema. However, the description adds no additional meaning or context for the parameters; it just repeats the prerequisite note. With high schema coverage, the baseline is 3, but since the description provides zero additional value, the score is reduced to 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes '[L:WRITE]' and 'CAT:[账户-子账户]' hinting at a write operation on subaccounts, but the main content '→ 请先调用 agent_catalog' is a prerequisite instruction rather than a clear statement of what the tool does. The verb and resource are implied by the tool name, but the description fails to explicitly state 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only instructs to call 'agent_catalog' first, providing minimal context. It does not explain when to use this tool versus alternatives, nor does it provide any exclusions or selection criteria. The prerequisite note is useful but insufficient for guiding 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, so description must disclose behavioral traits. It only signals a write level '[L:WRITE]' but omits side effects, authentication needs, error behavior, or what happens upon placement.
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?
Extremely short but lacks human-readable structure. The bracket notation is cryptic and not front-loaded with clear purpose. Every sentence should earn its place; this one-line description does not.
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, no annotations, and numerous sibling order tools, the description is severely incomplete. It fails to explain return values, required prerequisites (beyond agent_catalog), or how outcomes are specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description adds no extra semantic context for parameters beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is nearly tautological: 'place order' is already in the name. The cryptic format '[L:WRITE] CAT:[预测]' adds no clear verb or resource. Does not distinguish from sibling tools like okx_predictions_place_order.
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?
Description gives a prerequisite ('请先调用 agent_catalog'), which is a minimal usage hint. No guidance on when to use this vs. alternative order tools or how to determine event markets.
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 fails to disclose behavioral traits such as side effects, data scope, or permissions. Only a read hint is given, which 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but incomplete; it lacks essential information about the tool's purpose and usage, making it concise but not effective.
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 account bills and lack of output schema, the description should explain what bills are returned. It only notes a prerequisite, leaving the tool's functionality largely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all parameters (100% coverage), so the tool description does not need to add more. Baseline score of 3 is appropriate as description adds no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides only a read hint and category label without stating the tool's function or what resource it acts on. The verb 'get' is in the name but the description does not clarify it retrieves account bills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like okx_get_bills or okx_get_account_bills_archive. The mention to call agent_catalog first is a prerequisite but does not address selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only hints at read-only via '[L:READ]' but does not disclose any behavioral traits such as authentication requirements, rate limits, or what happens if agent_catalog has not been called. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks clarity and structure. While conciseness is valuable, it under-specifies the tool's purpose and usage, making it cryptic rather than efficient. Every sentence should earn its place; here, the instruction to call agent_catalog is not fully explained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter and no output schema, the description should at least explain what the tool returns or how to interpret the output. It fails to do so. The dependency on agent_catalog is mentioned but not elaborated, leaving the agent uncertain about preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% ('计价币种，如 USD、CNY。不填默认按所有币种'), so the baseline is 3. The description '请先调用 agent_catalog' does not add meaning to the parameter, and the parameter is adequately explained in the schema. No additional semantics added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[账户]' and a Chinese instruction to call agent_catalog first, but does not explicitly state that the tool retrieves asset valuation. The name implies the purpose, but the description itself is vague and requires inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings (e.g., okx_get_balance, okx_get_account_bills). The only instruction is to call agent_catalog first, which is a prerequisite, not a usage guideline. No alternatives or context provided.
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 available, and the description only includes '[L:READ]' which suggests a read operation but is not confirmed. There is no disclosure of side effects, data scope, or prerequisites beyond the cryptic instruction. The description fails to provide behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not well-structured or informative. It uses non-standard formatting (brackets, Chinese text) which may confuse an agent. The instruction is not a clear description of the tool's function.
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 has no parameters or output schema, the description should still explain what the tool returns and how it fits into the workflow. The instruction to call agent_catalog implies a dependency, but the tool's purpose and output are completely unexplained. The description is insufficient 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 tool has zero parameters, so the input schema is trivial. According to the scoring guidelines, zero parameters warrant a baseline of 4. The description does not add parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[资金] | → 请先调用 agent_catalog' is cryptic and does not clearly state that the tool retrieves deposit/withdrawal status. The name hints at it, but the description does not confirm the purpose or what resource is being accessed. It is vague and incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like okx_get_deposit_history or okx_get_withdrawal_history. The instruction to call agent_catalog first is a prerequisite but 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description gives a read hint ([L:READ]) but no annotations exist. It fails to disclose any behavioral traits such as data scope, rate limits, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but is under-specified and cryptic rather than concise. It wastes space on unclear notes.
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 tool that retrieves instruments from a large exchange with many similar tools, the description lacks any detail on returned data, filtering, or prerequisites, making it nearly useless.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3. The description adds no parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a cryptic categorization note and a prerequisite. The purpose is implied by the name but not clarified.
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 okx_search_instruments. The hint to call agent_catalog is vague and unexplained.
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 tag '[L:READ]' hints that the tool is a read operation, but the description does not disclose other behaviors (e.g., authentication needs, rate limits, or side effects). No annotations are provided to compensate.
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 (one line) but it is a tag, not a clear explanation. It is underspecified rather than concise, and the important 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?
The description completely fails to explain what the tool returns, when to use it, or how it fits among siblings. For a tool with no output schema and minimal annotations, the description is wholly inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters. The description adds no additional meaning beyond the schema, but the schema itself is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tag ('[L:READ] CAT:[账户] | → 请先调用 agent_catalog') that does not state the tool's purpose. It does not explain that the tool retrieves the maximum order size or what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is '请先调用 agent_catalog' (call agent_catalog first), which implies a prerequisite but does not explain when to use this tool vs alternatives or provide 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 but only provides a vague '[L:READ]' hint and a catalog reference. It fails to disclose key traits like pagination, data format, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description sacrifices clarity for brevity. The cryptic format and missing action verb make it under-specified, not concise.
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 3 parameters and no output schema, the description is completely inadequate. It leaves the agent without enough context to understand what data the tool retrieves or 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 100%, with descriptions for all parameters. The description adds no extra meaning beyond the schema, which is adequate, earning a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[统计] | → 请先调用 agent_catalog' is cryptic and does not specify a clear verb or resource. It lacks a clear purpose statement, making it hard to understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like okx_get_open_interest or okx_get_open_interest_history. The only instruction is to call agent_catalog first, which is a prerequisite, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It only indicates a read operation but lacks any information about side effects, authentication needs, rate limits, or data characteristics.
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, consisting of a single line with tags and a prerequisite note. While not verbose, it lacks substantive content and could be more informative without sacrificing conciseness.
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 the domain with numerous sibling spread tools and no output schema, the description is severely incomplete. It fails to explain what data is returned, how to use the response, or how this tool fits into a workflow.
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 covers the single required parameter with a clear description in Chinese. The tool description adds no additional meaning beyond what the schema already provides, so it does not improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is minimal, using tags '[L:READ] CAT:[策略-价差]' to hint at a read operation for spread books, but it does not clearly define what 'spread books' are or differentiate from sibling tools like okx_get_spread_orderbook or okx_get_spreads.
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 a prerequisite hint '请先调用 agent_catalog', but provides no guidance on when to use this tool versus the many other spread-related tools, nor does it explain the context in which this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The label '[L:READ]' hints that this is a read operation, but no annotations are provided to confirm or elaborate. The description does not disclose any behavioral traits such as data freshness, authorization requirements, or side effects. With no annotations, the description carries the burden but offers minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of a single line. While concise, it is under-specified and fails to convey the tool's purpose or behavior. Every sentence should earn its place, but this one omits critical information, making it more an instruction than a proper description.
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 the tool environment with many sibling tools, the description is completely inadequate. It does not explain what the tool returns, when to use it, or how it differs from similar tools like okx_get_stable_rewards_apy. The prerequisite is noted but without any context about the tool's functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema description coverage is 100%. The description adds no parameter information, but none is needed. A baseline score of 3 is appropriate because the schema already handles the param semantics fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a category label and a prerequisite to call agent_catalog. The tool name 'get_stable_rewards_product' suggests a read operation, but the description fails to clarify the specific resource or action. This is a tautology of the name at best, and at worst, it omits the core 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 includes a directive to call agent_catalog first, which is a prerequisite for using the tool. However, it provides no guidance on when to use this tool versus alternatives like okx_get_stable_rewards_apy or okx_get_stable_rewards_history. The context for selection is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only includes '[L:READ]' hinting at a read operation, but lacks details about rate limits, authentication needs, side effects, or what the tool does beyond reading. The description is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the brevity comes at the expense of clarity. It fails to provide essential information, making it under-informative rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the tool's complexity (4 parameters), the description does not explain what data is returned or how the tool fits into broader usage. The instruction to call agent_catalog adds confusion rather than completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters with descriptions. The description adds no additional semantic value beyond what is in the schema, maintaining the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state that the tool retrieves taker flow data for OKX. It only provides a cryptic instruction to call agent_catalog first, leaving the actual purpose unclear. The name suggests the purpose but the description fails to articulate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools like okx_get_taker_volume or okx_get_taker_flow_contract. There is no mention of use cases, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral details such as authentication requirements, rate limits, or error handling. The '[L:WRITE]' hint is minimal and 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 very short, which favors conciseness, but it is not clearly structured for an AI agent, using brackets and Chinese labels that may be opaque. It sacrifices clarity 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?
Placing an algorithmic order is a complex operation requiring many parameters (e.g., instrument, size, algo type). The description provides no guidance on parameters, return values, or prerequisites beyond calling agent_catalog. This is severely 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 only parameter 'params' is an object with a vague description referencing OKX docs. This adds little meaning beyond the schema, which is also generic (additionalProperties allowed). The agent gains no insight into required fields or structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic labels like '[L:WRITE]' and 'CAT:[交易-委托]' instead of a clear statement of what the tool does. While the name suggests placing an algorithmic order, the description does not explicitly state that purpose, leading to 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 only provides a prerequisite ('请先调用 agent_catalog') but offers no guidance on when to use this tool versus alternatives like 'okx_place_order' or other algo order tools, nor does it explain exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral disclosure. With no annotations, the description must carry the full burden. It does not state what is cancelled (open orders? positions?), the scope (by asset IDs or all?), side effects, or reversibility. This is a critical gap for a potentially destructive write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this conciseness sacrifices informative content. While it avoids verbosity, it fails to communicate essential details, making it less than effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complex nature (potential bulk cancellation), the absence of an output schema and lack of explanation about what is cancelled, prerequisites, or confirmations make the description completely inadequate for an agent to use safely and 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?
The input schema has one optional parameter 'assetIds' with 100% description coverage. However, the description adds no additional meaning beyond what the schema provides. It does not explain how the parameter affects the cancellation (e.g., filter or scope), leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:WRITE] CAT:[预测]' and a prerequisite reference, but does not clearly state the tool's purpose. The name 'cancel_all' suggests cancelling all predictions orders, but the description fails to articulate this in plain language, making it vague for differentiation from sibling tools like 'okx_predictions_cancel_order'.
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 only provides a prerequisite ('call agent_catalog first') but no guidance on when to use this tool versus alternatives like individual cancel or other mass cancel tools. It does not specify context, exclusions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only contains a read hint. It does not disclose behavior such as authentication requirements, rate limits, or side effects. The minimal description fails to inform the agent about important behavioral traits beyond the inferred 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is not conciseness; it is under-specification. A valid description should be concise yet informative. This one omits crucial information, making it insufficient for correct tool selection.
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 two optional parameters and no output schema, the description is severely incomplete. It does not clarify the return format, the meaning of 'predictions positions', or how to interpret results. The tool appears complex due to its domain (predictions), yet the description provides almost no contextual help.
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 coverage is 100%, but the description adds no meaning to the parameters 'status' and 'marketId'. It does not explain their purpose or acceptable values beyond the schema descriptions. The description is entirely generic and does not compensate for any lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is minimal and does not clearly state the action. 'L:READ' hints at a read operation, but the purpose of retrieving 'predictions positions' is not explicitly articulated. The name itself is more informative than the description.
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 a prerequisite to call 'agent_catalog' first, which provides some usage context. However, there is no guidance on when to use this tool versus similar tools like 'okx_get_positions' or other prediction tools. The prerequisite is noted but lacks situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. The '[L:READ]' tag hints at read-only access, but it's informal and not a standard annotation. No other behavioral traits (e.g., what data it accesses, side effects, permissions) are described.
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 but under-specified. It lacks essential information about the tool's purpose and usage, making it insufficient for the agent to understand its function.
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 lack of output schema and annotations, the description should provide context on what the tool returns. It fails to do so, leaving the agent with no understanding of the tool's output or 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 one optional parameter with full description in the schema. The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It provides tags '[L:READ]' and 'CAT:[Smart Money]' and a prerequisite instruction, but no verb or clear indication of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('请先调用 agent_catalog') which implies a sequence, but there is no guidance on when to use this tool versus alternatives or any exclusion criteria. It does not help the agent decide among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It does not state whether the tool is read-only (despite '[L:READ]') or mutating, nor any side effects, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the cost of clarity. It is not well-structured and contains cryptic codes that reduce its helpfulness.
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 lack of annotations, output schema, and minimal description, the tool definition is entirely incomplete for an agent to understand its usage, return values, or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have basic descriptions. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and does not explicitly state that the tool sends a message to a room. It includes '[L:READ] CAT:[系统]' and a dependency instruction, but the core 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?
The description provides a prerequisite ('call agent_catalog first') but no guidance on when to use this tool versus alternatives like agent_room_view or other messaging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits such as side effects, permissions required, or whether the operation is reversible. The [L:WRITE] tag implies mutation but provides no further details.
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 but lacks essential information. It sacrifices completeness for brevity, making it unhelpful.
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 amending algo orders, the description is severely incomplete. It lacks information about return values, error handling, prerequisites (beyond calling agent_catalog), and any behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is documented in the schema. However, the description adds no additional meaning or context beyond what the schema already provides.
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 only provides a write indicator and a category tag, but fails to explicitly state that this tool amends algorithmic orders. The description essentially restates the tool name's implication without adding 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 on when to use this tool over alternatives like cancel_algo_order or place_algo_order. The instruction to call agent_catalog first is a prerequisite, 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.
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 such as side effects, permissions, or whether the operation is irreversible.
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 overly terse and cryptic, lacking proper structure. It is concise but at the expense of clarity and usefulness.
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 write operation with no output schema, the description is woefully inadequate. It omits critical context like what happens when a redemption is canceled and does not compensate for missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a Chinese description for the 'amt' parameter. The tool description adds nothing beyond the schema, so baseline 3 applies given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic with metadata tags and a note to call agent_catalog. It does not clearly state that this tool cancels an ETH redemption, relying on the tool name and schema for meaning.
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 only hints at a prerequisite ('请先调用 agent_catalog') but does not explain when to use this tool versus alternatives like okx_unstake_eth or okx_cancel_order.
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 information such as effects, permissions, rate limits, or error conditions. This is a critical gap.
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 but fails to provide a coherent explanation of the tool's function. It appears to be an internal tag rather than a user-facing description, making it under-specified.
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 simplicity (one parameter, no output schema), the description should at least state 'Cancels an RFQ by ID.' Instead, it omits the core action and offers only a prerequisite hint, leading to poor completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter (rfqId) clearly. The description adds no new semantic value, but coverage is 100%, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state that the tool cancels an RFQ; it only contains a cryptic tag and a reference to another tool. The purpose is mostly inferred from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction '请先调用 agent_catalog' implies a prerequisite but no guidance on when to use this tool versus alternatives like okx_cancel_all_rfqs or okx_cancel_batch_rfqs.
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 that this tool deletes an API key irreversibly. The '[L:READ]' label falsely implies a read-only operation. Behavioral traits are completely obscured.
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 but not effectively concise—it includes cryptic abbreviations and Chinese text without clear English meaning. It does not efficiently convey the tool's 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 no annotations and no output schema, the description should provide comprehensive context. It fails to explain return values, side effects, prerequisites (beyond a vague 'call agent_catalog'), or any behavioral traits. Completely inadequate for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with Chinese descriptions for both parameters (subAcct, apiKey). The description adds no additional parameter-level meaning; it simply directs to call agent_catalog. Baseline score of 3 is appropriate as schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a misleading '[L:READ]' label conflicting with the 'delete' action in the name, and the Chinese category and instruction to call agent_catalog first without clarifying what the tool does. Purpose is unclear and contradictory.
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 only mentions calling agent_catalog first, but provides no guidance on when to use this tool versus its siblings (e.g., create, reset, get subaccount API key). No context for appropriate usage.
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 does not disclose behavioral traits such as authorization requirements, rate limits, or side effects. The '[L:WRITE]' tag vaguely implies a write operation, but this is not explicit or informative.
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 (two tags and a prerequisite instruction), but it lacks substance. It is under-specified rather than concise, as it fails to provide essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (amending an order in event markets) and the absence of an output schema, the description is severely incomplete. It does not explain return values, constraints, or examples. The tool cannot be used effectively with this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 4 parameters (instId, ordId, newPx, newSz) with Chinese descriptions. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:WRITE]' and 'CAT:[预测]' which hint at a write operation for predictions, but does not explicitly state what the tool does (amending an order). The tool name 'okx_event_amend_order' provides some clarity, but the description itself is insufficient.
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 instructs to call 'agent_catalog' first, which is a prerequisite, but provides no guidance on when to use this tool versus alternatives like 'okx_place_order' or 'okx_cancel_order'. No differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The '[L:READ]' tag hints at read-only but is not standard. No mention of side effects, permissions, rate limits, or data returned. The description does not disclose behavioral traits beyond the tag.
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?
Extremely short but not front-loaded with essential information. The few words are cryptic and barely more than a label. Conciseness is not helpful when it omits critical purpose and usage details.
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 explanation of return values, and the domain (event instruments) is complex. The agent lacks essential context to understand what this tool returns or how to use results. Very 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 describes seriesId with a Chinese description (事件系列ID). The description adds no further meaning or usage context for the parameter. With 100% schema coverage, baseline is 3, but the description fails to add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic ('[L:READ] CAT:[预测]') and only instructs to call agent_catalog first. It does not state what the tool does (e.g., 'get event instruments'). The name gives some clue but the description fails to 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is '请先调用 agent_catalog' (call agent_catalog first), implying a dependency. No explicit when-to-use or when-not-to-use compared to siblings like okx_get_event_events or outcomes_list_events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. The tag '[L:READ]' suggests a read operation, but executing a quote is clearly a write/mutation. This internal contradiction misleads the agent about the tool's side effects. No other behavioral aspects (e.g., permissions, idempotency) are mentioned.
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 (one line) but lacks essential information, making it under-specified rather than concise. Every sentence should earn its place, but here the single sentence is insufficient.
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 executing a quote (a trading operation), the description is severely incomplete. No output schema, no explanation of the tool's function, no error conditions, no safety or idempotency notes. The prerequisite is vague ('call agent_catalog').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with each parameter having a Chinese description (e.g., '成交数量'). However, these descriptions merely restate the parameter purpose and do not add meaningful context beyond the schema. Parameter semantics are minimally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides tags like '[L:READ]' and a category 'CAT:[策略-RFQ]' but fails to explicitly state that this tool executes a quote. The purpose is only implied by the tool name, and the description does not clarify what action is performed.
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 a prerequisite ('请先调用 agent_catalog') but provides no guidance on when to use this tool versus sibling RFQ tools (e.g., okx_create_quote, okx_cancel_quote). No 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only indicates it is a read operation. It does not disclose side effects, authorization requirements, rate limits, or any behavioral traits beyond the implicit 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one line) but lacks clarity and structure. It is not front-loaded with the primary purpose and includes a confusing prerequisite. It sacrifices completeness 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?
Given the absence of annotations and output schema, and the minimal description, the tool definition is incomplete. It fails to explain what the tool returns, its context, or how it fits with sibling tools, leaving the agent without adequate information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description adds no parameter information, but since there are no parameters, it does not need to. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes '[L:READ]' indicating it's a read operation and 'CAT:[交易]' for trading category, but it does not state what resource or function is being accessed (e.g., account rate limits). It redirects to 'agent_catalog' without explaining the tool's core 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 only mentions a prerequisite ('请先调用 agent_catalog'), but does not provide guidance on when to use this tool versus its many siblings (e.g., okx_get_ticker, okx_get_balance). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. The [L:READ] tag weakly implies a read operation, but there is no mention of data range, pagination, rate limits, or any behavioral traits. For a 3-parameter 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not concise in a useful way—it uses cryptic tags and a one-line instruction. It fails to front-load clear information about tool purpose or behavior.
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 has 3 parameters (2 required, all enums), no output schema, and many sibling tools dealing with orders, the description is critically incomplete. It does not differentiate this tool from similar ones or explain the scope of 'history'. The dependency on agent_catalog is not enough.
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 100% and the schema already describes parameters with enums and Chinese labels. The description adds zero extra meaning beyond a dependency note. With high coverage, baseline is 3, but the description provides no value, hence 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description relies on tags like [L:READ] and a Chinese category label rather than a clear statement of what the tool does. 'CAT:[交易-委托]' suggests algo orders, but the verb+resource is missing. The agent must infer from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guideline is '→ 请先调用 agent_catalog', which indicates a dependency but does not explain when to use this tool over siblings like okx_get_algo_orders or okx_get_orders_algo_pending. No alternative or context is provided.
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, so description must disclose behavior. It only gives a category and a prerequisite, omitting traits like data freshness, pagination, rate limits, or effects. Virtually no behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but inefficient, using cryptic tags (L:READ, CAT:[行情]) and a prerequisite note. It could be more concise and directly state the tool's purpose. Not every sentence earns its place.
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?
Despite low complexity (3 params, no output schema), the description is severely incomplete. It does not explain the return format, when to use this vs history candles, or any context. The prerequisite instruction is unhelpful without further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters (bar, limit, instId). The description adds no additional meaning beyond the schema. Baseline score of 3 applies per guidelines.
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 is vague: '[L:READ] CAT:[行情] | → 请先调用 agent_catalog'. It labels it as read and market data category but does not state 'Get candles' or specify the action. The name implies OHLCV data, but the description itself lacks a clear verb+resource statement. No differentiation from sibling tools like okx_get_history_candles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance provided. The instruction to call agent_catalog first is a prerequisite, not a guideline on when to use this tool versus alternatives. No mention of 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 provided, so description carries full burden. It only hints at a read operation via '[L:READ]', but does not disclose behavioral traits like side effects, authentication needs, or rate limits. Agent gets almost no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an underspecified tag line, not a proper description. It fails to earn its place by providing minimal useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters and no output schema or annotations, the description is completely inadequate. It does not explain the return value, how to interpret the quote, or any usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for fromCcy, toCcy, and sz. The description adds no extra meaning, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague: it only contains tags '[L:READ] CAT:[资金]' and a prerequisite call. It does not explicitly state that the tool gets a convert estimate quote, relying on the tool name. No differentiation from sibling tools like okx_create_quote or okx_get_convert_currency_pair.
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?
Only mentions a prerequisite ('请先调用 agent_catalog'), but provides no guidance on when to use this tool versus alternatives. With many conversion-related siblings, the agent lacks 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?
With no annotations, the description must disclose behavioral traits. It provides only a read hint and category, but no information on pagination, authentication, rate limits, or whether it is destructive. The description is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks critical information. It is not concise in a helpful sense; it is under-specified. Every sentence should earn its place, but here the sentences are insufficient.
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 has one parameter and no output schema or annotations, the description should clearly state what the tool returns and any additional context. It fails to do so, and does not explain its relationship to other staking tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'limit' parameter, which already describes its meaning and constraints. The description adds no additional meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only contains metadata flags '[L:READ] CAT:[金融]' and a prerequisite instruction, but does not explicitly state that the tool retrieves ETH staking history. The name implies the purpose, but the description itself is 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 guidelines on when to use this tool versus alternatives like 'okx_get_eth_staking_balance' or 'okx_get_sol_staking_history'. The only instruction is to call agent_catalog first, which is a prerequisite but not a usage guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only includes a read hint via '[L:READ]' but does not explain side effects, authentication requirements, rate limits, or what the response contains. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line), but it sacrifices clarity for brevity. It uses non-standard tags that are not self-explanatory, and the prerequisite instruction is not front-loaded. It is under-specified rather than efficiently concise.
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 lack of output schema and the complexity of the tool ecosystem (many siblings), the description does not explain the return value, the meaning of 'events' in this context, or how it relates to the prerequisite agent_catalog. Complete guidance 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?
There is one parameter (seriesId) with 100% schema coverage. The schema already describes it as required and provides a description. The tool description does not add any additional meaning or usage nuance beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[预测]' but lacks a clear verb and resource. It does not explicitly state what the tool does (e.g., 'Get list of events for a series'). The purpose is vague and relies on the name and tags for interpretation.
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 a prerequisite instruction ('→ 请先调用 agent_catalog'), but provides no guidance on when to use this tool versus its many sibling tools (e.g., okx_get_event_series, outcomes_list_events). No differentiation or context for selection is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must compensate. The '[L:READ]' tag indicates a read operation, which is helpful, but there is no disclosure of data freshness, pagination behavior, permissions, or any side effects. The description is 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-informative. It fails to deliver necessary details, making it incomplete rather than concise. Every sentence should earn its place; this one does not.
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 3 parameters, no output schema, and large sibling set, the description is severely incomplete. It lacks any detail about return format, usage context, or tie-in to the broader API. The instruction to call 'agent_catalog' is cryptic and does not substitute for proper documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it merely contains a category tag and a prerequisite note. The parameter descriptions in the schema are adequate on their own.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague. The name 'get_fills_history' and the category tag '[交易]' hint at retrieving historical trade fills, but the description fails to explicitly state the action and resource. It only says '→ 请先调用 agent_catalog' without defining the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'okx_get_fills' or other fill-related tools. The prerequisite to call 'agent_catalog' is mentioned but not explained, and no alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. The label '[L:READ]' hints at read-only, but it is not a standard annotation and is ambiguous. The description does not mention pagination, rate limits, data periods, or any other behavioral traits. This is severely lacking.
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 but at the cost of omitting essential information. It under-specifies rather than being concise. There is no wasted text, but the trade-off is poor completeness.
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 tool with 4 parameters, no output schema, and no annotations, the description is critically incomplete. It fails to explain the return format, pagination details, or any context about funding rate history. The note to call agent_catalog suggests additional context is needed, which is a sign of missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The tool description adds no extra meaning for parameters beyond what the schema provides. Baseline 3 is appropriate as the schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just a label '[L:READ]' and category 'CAT:[公共]' with a note to call agent_catalog. It does not explicitly state that the tool retrieves historical funding rates for OKX instruments. The purpose can be inferred from the name, but the description itself is vague and lacks a clear verb+resource statement.
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 sibling 'okx_get_funding_rate' likely returns the current funding rate, but this distinction is not mentioned. The note to call agent_catalog first is a prerequisite, not usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only hints at read-only via '[L:READ]' but offers no details on data returned, rate limits, or side effects. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but cryptic and uninformative. It uses tags that obscure rather than clarify, reducing effectiveness.
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 and numerous siblings, the description fails to explain returns, use cases, or how it differs from similar ratio tools. Without output schema, completeness is critically lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter meanings (currency, timestamps). The description adds no additional parameter context, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[统计]' without clearly stating the tool's function. While the name suggests it retrieves long-short account ratio, the description does not explicitly confirm this or differentiate it from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction '请先调用 agent_catalog' indicates a precondition but provides no guidance on when to use this tool versus alternatives like okx_get_long_short_ratio or okx_get_contracts_long_short_ratio. The agent lacks context for decision-making.
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 includes a cryptic tag '[L:READ]' which is non-standard. It discloses no behavioral traits such as side effects, permissions, or response behavior. With no annotations, the description fails to inform the agent about safety or behavior.
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 but cryptic, using non-standard formatting (brackets, arrow) that reduces clarity. While concise in token count, it is not effectively structured for agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should fully explain the tool's purpose and return values. It barely describes the tool and requires a separate catalog call, leaving the agent without enough context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional semantic value beyond what the schema already provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic ('[L:READ] CAT:[账户] | → 请先调用 agent_catalog'). It indicates a read operation on account category but does not explicitly state that the tool retrieves the max loan amount, nor does it differentiate from siblings like okx_get_max_size or okx_get_max_withdrawal.
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 instructs to call agent_catalog first, providing some prerequisite guidance, but no explanation of when to use this tool vs alternatives, nor exclusions. The usage context remains unclear.
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 it is a read operation via '[L:READ]', but no annotations are provided. It does not disclose any other behavioral traits like side effects, rate limits, or data freshness. The description fails to compensate 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specifies the tool. It is not concise in a helpful way; it lacks essential information. Every sentence should contribute, but this single line does not adequately describe the tool.
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 annotations, the description is severely incomplete. It does not explain what the historical data contains, the return format, or any usage context. The note to call agent_catalog is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (instId, limit, period). The description adds no value beyond that, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a read label and category. The purpose is implied by the name but not clarified. This is minimal and 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives, such as okx_get_open_interest or other historical data tools. The suggestion to call agent_catalog is vague and doesn't help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description includes '[L:READ]', which may indicate a read-only operation, but this is ambiguous and not elaborated. No further behavioral traits (e.g., safety, idempotency, rate limits) are disclosed. The description does not contradict any annotations because none exist.
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 (one line), but it is under-specified rather than concise. It lacks essential information and uses a non-English phrase. Every sentence must earn its place, but this description does not provide enough value for its 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?
Given the tool's complexity (options OI ratio with timestamp parameters) and the absence of an output schema, the description is severely incomplete. It does not explain the return format, what the ratio represents, or any nuances. With many sibling tools, a more complete description is necessary for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (ccy, end, begin) have descriptions in the schema. The tool description adds no additional meaning beyond the schema. According to guidelines, when coverage is high, baseline score is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is minimal and in Chinese. It does not explicitly state what the tool does beyond the name 'okx_get_option_oi_ratio', which hints at retrieving the option open interest ratio. However, no verb or resource description is provided, making it vague. Sibling tools like 'okx_get_option_open_interest' suggest a family of related tools, but no differentiation is given.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The only instruction is '请先调用 agent_catalog' (please call agent_catalog first), which is a prerequisite rather than usage direction. There is no mention of when or when not to use this tool, or any comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It includes a read hint '[L:READ]' but does not disclose any behavioral traits such as authentication needs, rate limits, or side effects. More context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks essential information. It is not concise because it omits critical purpose and usage details, making it more of a placeholder than a well-structured description.
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 (archived orders history) and the presence of many similar sibling tools, the description is incomplete. No output schema is provided, and the description fails to explain what 'archive' means, how results are ordered, or how this tool differs from others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the input schema descriptions adequately explain 'limit' and 'instType'. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[交易]' does not explicitly state what the tool does. It suggests a read operation and a trading category but lacks a verb and resource. It does not differentiate from siblings like 'okx_get_orders_history' or 'okx_get_orders_archive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The only instruction is to call 'agent_catalog' first, which is a prerequisite but does not clarify usage 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 provided, the description carries the full burden. It only includes a self-declared '[L:READ]' hint, but no details on side effects, auth needs, rate limits, or other behavioral traits. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the cost of being uninformative. It is under-specified, not concise in a helpful way; every sentence should earn its place, but here it fails to convey core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is incomplete. It lacks a clear statement of what the tool retrieves and does not adequately set context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'ccy' with 100% coverage. The tool description adds no additional semantic value beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a label '[L:READ] CAT:[金融]' and an instruction to call 'agent_catalog'. The tool's name suggests retrieving savings balance, but the description fails to confirm this.
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 mention of 'agent_catalog' is vague and does not clarify usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only declares '[L:READ]' (likely read-only) and a category, but omits critical behavioral details such as authentication requirements, error handling, or side effects. This is completely inadequate for a tool that likely involves retrieving order data.
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 but not effectively concise because it uses cryptic codes like '[L:READ] CAT:[策略-信号]' instead of plain language. It lacks structure and front-loads no useful information for an AI agent.
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 simple tool with one parameter and no output schema, the description should at least state what the tool returns and when to use it. It fails to provide any such context, leaving the agent without enough information to decide on usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter (algoId) with a description in Chinese meaning 'signal bot ID, required'. Since schema coverage is 100%, the description adds no additional value for parameter semantics. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[策略-信号]' does not explicitly state what the tool does. The tool name 'okx_get_signal_orders' hints at retrieving signal orders, but the description fails to provide a clear verb+resource. It also does not differentiate from sibling tools like okx_get_signal_bots_pending or okx_get_signal_positions.
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 a prerequisite instruction ('请先调用 agent_catalog') but does not specify when to use this tool versus alternatives. No comparisons or exclusions are provided, leaving the agent uncertain about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, yet the description provides no behavioral context such as rate limits, authentication, or side effects. The label '[L:READ]' hints at a read operation but is insufficient and not explicitly 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 very short but not well-structured. It mixes metadata and a prerequisite note without a clear statement of purpose. While concise, it lacks clarity and proper organization.
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 and lack of output schema, the description is severely incomplete. It does not explain what the tool returns, how to interpret results, or any constraints beyond schema parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with Chinese descriptions for both parameters (ccy and instId). The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic labels like '[L:READ]' and 'CAT:[统计]' without explicitly stating that the tool retrieves taker volume for contracts. The name implies the function but the description fails to clarify it for an AI agent.
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 sibling tools like 'okx_get_taker_volume' or 'okx_get_contracts_taker_volume'. The prerequisite 'call agent_catalog' suggests documentation but does not provide direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only labels the tool as read and gives a category, with no information on side effects, authentication, rate limits, or what data is returned. Completely 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 extremely short and concise, but it relies on cryptic labels and a prerequisite note. While not verbose, it sacrifices clarity for brevity. Could be restructured for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the tool returns and how it relates to sibling tools. It fails to do so, providing only a category label and a reference to agent_catalog. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% trivially. The description does not add parameter meaning, but baseline for 0 params is 4. No deduction needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses labels '[L:READ]' and 'CAT:[策略-跟单]' to hint at read operation and copy trading category, but does not explicitly state that the tool retrieves total unrealized profit sharing. The name is descriptive, but the description lacks a clear verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like okx_get_unrealized_profit_sharing or okx_get_profit_sharing_total. The only instruction is to call agent_catalog first, but no context on when to choose this tool.
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 and no behavioral disclosure. The description does not mention whether this tool is read-only, what actions it performs, or any side effects. The prerequisite hint is unclear and insufficient.
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 but contains non-English text and unclear symbols. It does not effectively communicate the tool's purpose, making it not genuinely concise.
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 lacks essential information about return values, behavior, and context. Given no output schema, the description must explain what the tool returns, but it fails to do so. The prerequisite is ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 each parameter has a description. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It contains a cryptic note '[L:READ] CAT:[账户]' and a prerequisite to call agent_catalog, but does not explain the purpose of 'okx_get_trade_fee'. The tool name suggests retrieving trade fees, but the description fails to convey that.
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 note '请先调用 agent_catalog' implies a prerequisite but is not helpful for usage decision. No explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fails to disclose any behavioral traits such as read-only nature (though '[L:READ]' may be a hint), side effects, or authentication requirements. The tag 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it sacrifices substance for brevity. It lacks useful information and the structure (tag + instruction) is minimal.
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 (many indicator options, period, bar), the description is severely incomplete. It does not explain what returns to expect or how to interpret results, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters documented), so baseline is 3. The description adds no additional meaning beyond the schema, but does not repeat or contradict it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes '[L:READ] CAT:[行情]' which hints at market data, but it does not explicitly state that the tool computes technical indicators. It mainly directs to call agent_catalog first, leaving the core purpose 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?
The description specifies a prerequisite (call agent_catalog first), but provides no guidance on when to use this tool versus sibling tools like okx_get_candles or okx_indicator_batch. No differentiation is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility. It only includes '[L:WRITE]' indicating a write operation but fails to disclose any behavioral traits such as authorization needs, side effects, rate limits, or what the tool modifies. The description is nearly devoid of behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but not effectively concise. It uses a cryptic format ('[L:WRITE] CAT:[交易]') that requires decoding and lacks standard structure. While short, it sacrifices clarity and fails to convey useful information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and only a minimal description. It does not explain what the tool returns, the outcome of the repayment, or any error conditions. For a financial operation with two required parameters, this level of detail is severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (ccy, repayCcy) with descriptions in the schema itself (100% coverage). The description adds no additional meaning or clarification beyond the schema. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name 'one_click_repay' suggests a repayment function, but the description only provides a write label and category without stating the actual operation. The phrase '请先调用 agent_catalog' is a prerequisite, not a purpose statement. This leaves the agent uncertain about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to call 'agent_catalog' first, which is a usage prerequisite. However, it does not specify when to use this tool versus alternatives like 'okx_borrow_repay' or other trading tools. No exclusions or context are provided beyond the prerequisite.
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 offers no behavioral traits beyond the unclear '[L:READ]' tag. There is no mention of side effects, authentication requirements, rate limits, or what the tool does to state. The description is utterly insufficient for 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the cost of clarity. It front-loads tags but provides little useful content. Conciseness is only valuable when it maintains informativeness; here it leaves the agent guessing.
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 likely complexity (position builder with parameters), the description is grossly incomplete. It lacks an explanation of return values, how to construct the 'body' parameter, and what constitutes a valid request. The single prerequisite does not compensate for the missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a description for 'body' ('试算参数JSON字符串。必填'). The tool description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic, using tags like '[L:READ]' and 'CAT:[账户]' without explaining what the tool does. It mentions a prerequisite but fails to state the tool's function clearly. The name suggests position building, but the description doesn't confirm or elaborate, leaving the purpose 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?
The only guidance is '请先调用 agent_catalog', which indicates a prerequisite but provides no context about when to use this tool versus siblings like okx_get_positions or okx_get_position_builder_graph. There is no discussion of alternatives or exclusions.
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 does not disclose any behavioral traits (e.g., read vs write, side effects, permissions). The cryptic '[L:READ]' is unclear and insufficient.
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 but not concise in a helpful way; it is cryptic and under-specified. It fails to efficiently convey useful 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?
For a tool with 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, behavior, or contextual requirements beyond a vague prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[金融] | → 请先调用 agent_catalog' does not clearly state what the tool does. The name suggests purchasing savings, but the description lacks a verb+resource structure and does not distinguish from siblings like okx_get_savings_balance.
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 instruction is to call agent_catalog first, which is a prerequisite but does not explain usage context or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavioral traits. It only indicates a write operation but does not disclose effects (e.g., enabling/disabling auto-loan), side effects, permissions, or rate limits. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely short, the description sacrifices informativeness for brevity. It does not effectively communicate what the tool does, leading to under-specification rather than conciseness.
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 a setting tool (likely with consequences) and no output schema or annotations, the description is grossly incomplete. It fails to explain what auto-loan is, how side affects it, or any prerequisites beyond calling agent_catalog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the built-in descriptions of ccy and side already explain their meaning. The description adds no extra semantic value, but the schema is sufficient; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states '[L:WRITE] CAT:[账户]' indicating a write operation in the account category, but fails to explicitly state the tool's purpose of setting auto-loan. The purpose is only inferable from the tool name, which is insufficient for an AI agent.
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 okx_borrow_repay or okx_set_auto_earn. The instruction to call agent_catalog first is vague and does not clarify use cases or conditions.
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 lacks any behavioral transparency. It does not mention whether the operation is idempotent, reversible, requires authentication, or has any side effects beyond a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it fails to provide necessary information. The instruction to call agent_catalog is important but poorly integrated. It could be more structured to convey purpose and usage succinctly.
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 write tool with 2 parameters and no output schema or annotations, the description is completely inadequate. It does not explain what the tool does, return behavior, or any operational considerations. The prerequisite hint is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with 'ccy' and 'rate' described as required fields. However, the description adds no additional meaning beyond the schema, such as formats, allowed values, or examples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a tag '[L:WRITE]' suggesting a write operation and 'CAT:[金融]' indicating finance, but it does not explicitly state that this tool sets a lending rate. The instruction to call agent_catalog first does not clarify the tool's function. Sibling tools like okx_get_lending_rate_summary suggest a related domain, but the purpose is 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?
The description only says '→ 请先调用 agent_catalog' (please call agent_catalog first). It does not provide any guidance on when to use this tool versus alternatives, nor does it explain prerequisites or exclusions.
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 lacks any behavioral disclosure such as side effects, authorization needs, or operational impact. The tool is a write operation, yet the description offers no insight into its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (a single line), but it is cryptic and lacks a clear structure. It is concise but at the expense of clarity and completeness.
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 has 4 required parameters and no output schema, the description is woefully incomplete. It fails to explain what MMP config is, how the parameters relate, or what the outcome of the operation is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the baseline is 3. The tool description does not add any additional parameter context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:WRITE] CAT:[交易]' and a note to call agent_catalog, but does not explicitly state that the tool sets MMP configuration. The purpose is implied but unclear, especially without 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?
It instructs to call agent_catalog first, providing a precondition, but gives no guidance on when to use this tool versus alternatives like okx_reset_mmp or okx_get_mmp_config.
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. The description adds minimal behavioral insight beyond the '[L:WRITE]' tag. It does not describe side effects, required permissions, or what changes occur when executing this 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 extremely short, but it is under-specified rather than concise. It lacks essential information, making it ineffective.
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 tool with only one parameter and no output schema, the description fails to explain the expected JSON structure, valid values, or effects. The tool is critical for configuration but is almost entirely opaque.
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 'jsonString' has a schema description that is nearly a tautology ('配置参数JSON字符串。必填'). Schema coverage is 100%, but the description adds no extra meaning; it does not specify required fields or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only includes tags like '[L:WRITE]' and 'CAT:[账户]' and a note to call agent_catalog first. It does not explicitly state what the tool does—e.g., which trading configuration is being set. The purpose is vague and relies on the name alone.
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 okx_set_account_mode or okx_set_leverage. The only instruction is to call agent_catalog first, but no further context or differentiation is provided.
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. The description only contains '[L:READ]' which hints at read-only nature but does not explain it. No disclosure of side effects, authentication needs, rate limits, or other behavioral traits. The burden is on the description, and it fails.
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) but lacks critical information. Conciseness is achieved at the expense of utility. Important details are missing, making it not effectively front-loaded.
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 does not explain what the tool returns (no output schema). It mentions a dependency on agent_catalog but does not describe the data or behavior. For a tool with three parameters and no output schema, this is grossly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its three parameters, so the baseline is 3. The tool description does not add further meaning to the parameters, but the schema already explains them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague. It includes 'CAT:[Smart Money]' and a prerequisite note, but does not explicitly state what the tool does (e.g., retrieves smart money leaderboard data). The name 'smart_leaderboard' implies the purpose but the description adds no 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?
The description provides a prerequisite ('call agent_catalog first') but no guidance on when to use this tool over siblings like okx_smart_trader_detail or okx_smart_sentiment. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as whether the operation is destructive, requires specific permissions, or has side effects. The only behavioral hint is a prerequisite note, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but wastes space on unexplained codes rather than a clear function statement. It is not front-loaded with the core purpose, making it ineffective despite its 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?
Given the tool has 6 parameters, no output schema, and no annotations, the description is grossly incomplete. It omits what the tool does, its return values, and any important behavioral context. The prerequisite note is insufficient to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: all 6 parameters have descriptions in the input schema. The description adds no additional meaning beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is minimal, using codes like 'L:WRITE' and 'CAT:[账户-子账户]' that are not explained in user-facing terms. It fails to clearly state that the tool performs a transfer between subaccounts. The schema hints at the functionality, but the description itself is 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?
The description mentions a prerequisite ('请先调用 agent_catalog'), but provides no guidance on when to use this tool over alternatives like okx_transfer or other subaccount tools. No context for selection among siblings.
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 does not disclose behavioral traits such as side effects, return format, or authentication needs. The '[L:READ]' hint is insufficient to convey behavior.
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 but fragmented with brackets and Chinese. It is not well-structured for an English-speaking AI agent, and the cryptic format reduces 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?
Given the tool's likely role in listing WebSocket events, the description is severely incomplete. No output schema is present, and the description does not explain what the tool returns or how the parameters are used beyond basic schema definitions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (limit, filter, subscriptionId) have descriptions in the input schema, covering 100% of parameters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[行情-WS] | → 请先调用 agent_catalog'. It vaguely suggests a read operation for WebSocket market data but does not provide a clear verb+resource. The tool's purpose is unclear without external context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('请先调用 agent_catalog'), but no guidance on when to use this tool versus alternatives like okx_ws_subscribe or okx_ws_status. The context is minimal and not 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?
With no annotations provided, the description carries full burden for behavioral disclosure. The '[L:READ]' tag hints at read-only behavior, but no details about authentication, rate limits, or side effects are given. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks essential information. It is not well-structured for an AI agent; it includes a prerequisite call but does not explain the tool's own function. Under-specification rather than proper conciseness.
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, 2 required, no output schema, and no annotations, the description is completely inadequate. It fails to explain return format, how results relate to sibling tools like okx_get_candles, or the prediction market context. Cannot effectively guide agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (bar, limit, outcome, marketId) have descriptions in the schema. The tool description adds no additional semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague; it only contains '[L:READ] CAT:[预测]' and a reference to calling agent_catalog. It does not explicitly state that the tool retrieves candlestick data for prediction market outcomes. The purpose is implied by the tool name but not clarified by the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like okx_get_candles or okx_predictions_candles. The only directive is to call agent_catalog first, which is a prerequisite, not a usage condition.
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 '[L:WRITE]' indicating a write operation but fails to highlight that canceling all RFQs is destructive. The prerequisite is noted, but overall transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but cryptic, using non-standard tags and a non-English phrase. While concise, it sacrifices clarity and structure, making it difficult for an AI agent to understand the tool's function.
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 lack of output schema and annotations, the description should provide complete context. It fails to explain return values, side effects, or the exact scope of 'all RFQs'. The sole prerequisite is insufficient for a destructive action 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, and schema coverage is 100%. Baseline for 0 parameters is 4. The description adds no parameter info, but none is needed. The prerequisite note is unrelated to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state the tool's purpose beyond what the name implies. It uses cryptic tags like '[L:WRITE] CAT:[策略-RFQ]' and a Chinese prerequisite, which obscures clarity. The tool name 'cancel_all_rfqs' suggests canceling all RFQs, but the description fails to articulate this directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like okx_cancel_rfq or okx_cancel_batch_rfqs. The description only includes a prerequisite ('请先调用 agent_catalog') without any context about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as side effects, permissions, rate limits, or whether the operation is truly read-only. The cryptic tag '[L:READ]' is not a clear behavioral statement. The agent has no insight into what this tool does 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but cryptic, using tags and Chinese without clear natural language. The prerequisite instruction is useful but the overall structure is not clear for an AI agent. It lacks explanatory text and is not well front-loaded with 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 no output schema and no annotations, the description is incomplete. It does not explain what the tool returns or what 'account config' means. The hint to call agent_catalog is vague. The agent cannot determine if this tool is useful 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 input schema has no parameters, so schema coverage is 100%. The description adds no parameter information, which is acceptable given zero parameters. Baseline is 4 for this case, and the description does not contradict the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[账户]' which suggest it is a read operation for account configuration, but it does not explicitly state what the tool does. The phrase '→ 请先调用 agent_catalog' is a prerequisite instruction, not a purpose statement. The tool name 'okx_get_account_config' is more informative than the description.
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 prerequisite ('call agent_catalog first') but does not explain when to use this tool versus other account-related sibling tools like okx_get_balance or okx_get_account_rate_limit. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It offers none—no mention of read-only status, rate limits, authentication requirements, or side effects. The cryptic '[L:READ]' might imply read-only but 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is poorly structured. The use of bracket codes and Chinese text without translation or explanation makes it less concise and harder to parse. The instruction to call agent_catalog is misplaced and disrupts 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?
For a simple tool with one parameter, the description should explain what 'call auction details' are and why agent_catalog is a prerequisite. It does neither, leaving the agent without enough context to understand when and how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'instId' with a clear description. The tool description adds no additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic codes like '[L:READ]' and 'CAT:[公共]' without explaining the tool's purpose. It references 'call auction details' in the name but fails to clarify what that means. The instruction to call agent_catalog first hints at a prerequisite but obscures the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus any sibling. The only usage hint is '请先调用 agent_catalog', which implies a prerequisite but does not explain why one would need this tool over alternatives like okx_get_ticker or okx_get_orderbook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only indicates read-only via '[L:READ]' but lacks any disclosure about side effects, authentication requirements, rate limits, or the format of returned data. The description is insufficient for an agent to anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two segments), which is concise, but it sacrifices clarity. The directive to call agent_catalog is front-loaded, but the overall lack of substance makes it less useful. It is not verbose, but it is also not adequately informative.
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 has no parameters, no output schema, and no annotations, the description should explain what data is returned and its relation to sibling tools. Instead, it only directs to agent_catalog, leaving the agent without sufficient context to use the tool correctly. The complexity is low, but the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% description coverage, so the baseline is 3. The description adds no additional semantic information beyond the schema. It does not explain what the tool fetches or how to interpret the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '[L:READ]' and 'CAT:[金融]' which hint at a read operation on financial data, but it does not clearly define what 'flexible loan collateral' means or what the tool returns. The phrase '→ 请先调用 agent_catalog' suggests it is not a standalone tool, muddying 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: '请先调用 agent_catalog'. It does not explain when to use this tool versus alternatives like okx_get_flexible_loan_info or okx_adjust_collateral, nor does it specify any context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description only includes '[L:READ]' which might indicate a read operation, but it's non-standard and insufficient. No details about side effects, authentication, rate limits, or return behavior are given.
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 but cryptic, using brackets and Chinese without clear structure. While concise, it sacrifices clarity and fails to effectively communicate the tool's 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 no output schema and low complexity, the description should at least clearly state that the tool gets interest rates. It does not, relying on the name. The note to call agent_catalog suggests incomplete self-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 100% for the single parameter 'ccy', which has a clear description (currency, optional, returns all if omitted). The tool description adds no further semantic meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and does not explicitly state that the tool retrieves interest rates. It uses non-standard tags like '[L:READ] CAT:[账户]' and a Chinese instruction to call agent_catalog first. The purpose is only indirectly implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage hint is '→ 请先调用 agent_catalog', which tells the agent to call agent_catalog first but does not specify when to use this tool vs alternatives. No differentiation from sibling tools like okx_get_funding_rate or okx_get_lending_rate_summary is provided.
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, yet the description fails to disclose any behavioral traits such as side effects, data returned, or required permissions. The sole hint '[L:READ]' suggests readonly but is not elaborated. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but not effective. It is structured as a terse note rather than a proper description, omitting essential information. Conciseness should not sacrifice clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required params, many sibling tools, no output schema), the description is incomplete. It does not explain return values, pagination, or how it fits into the broader copy trading workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters documented in the schema. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state the tool's purpose clearly. It includes a label '[L:READ]' and a category, but no indication that it retrieves lead trader statistics. The name suggests the function, but the description is 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?
The description mentions a prerequisite ('请先调用 agent_catalog') but offers no guidance on when to use this tool versus sibling tools like okx_get_lead_trader_positions or okx_get_lead_trader_history. No context on alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only includes '[L:READ]' suggesting read access, but does not disclose other behavioral traits (e.g., auth requirements, data scope, rate limits). The description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two short phrases) but fails to convey key information. It is under-specified rather than concise. Every sentence should earn its place, but here the text is insufficient for the tool's 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 3 optional parameters, no output schema, and many similar sibling tools, the description is incomplete. It does not explain what the tool returns or how it differs from alternatives. The note to call agent_catalog suggests a dependency but does not complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (100% coverage), so the description does not need to repeat them. It adds no additional meaning or context about parameters beyond the schema. Baseline score is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only contains a category label '[L:READ] CAT:[统计]' and a note to call agent_catalog. It does not state what the tool does (e.g., 'get long/short ratio for all coins'). The name suggests functionality, but the description is vague and does not clarify the verb or 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 is provided on when to use this tool versus siblings like okx_get_long_short_ratio or okx_get_contracts_long_short_ratio. The only instruction is to call agent_catalog first, which is a prerequisite but not a usage guideline 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, so the description carries the burden. It includes a read hint (L:READ) but does not disclose other behavioral traits such as permissions, side effects, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not concise in a helpful way; it is cryptic and lacks clear structure. It does not earn its place with valuable content.
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 (1 param, no output schema), the description is incomplete. It fails to explain return values or behavior, leaving the agent with minimal context beyond the name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter (ccy) with a clear description. The tool description adds no extra meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does beyond a category tag and a reference to another tool. The name 'get_max_withdrawal' hints at the purpose, but the description itself lacks clarity and fails to define the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 siblings. The description only directs to call agent_catalog first, which is not about tool selection 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?
Without annotations, the description must fully disclose behavior. It indicates a read operation via 'L:READ' but does not mention any required permissions, rate limits, error handling, or output format. The prerequisite hint is useful but insufficient.
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 but uses cryptic code-like prefixes that hinder readability. Important information (purpose, output) is missing, making it more confusing than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single param, no output schema), the description should clarify what data is returned (e.g., OI by expiry) and any grouping logic. The prerequisite note is helpful but does not cover the tool's primary function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the schema already describing the 'ccy' parameter as required currency. The description adds no additional meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic metadata like 'L:READ' and 'CAT:[统计]' but fails to explicitly state that the tool retrieves option open interest by expiry. The name suggests this, but the description does not confirm, leaving the purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is '请先调用 agent_catalog' (call agent_catalog first), which is a prerequisite. No information is given on when to use this tool vs. siblings like okx_get_option_oi_strike or okx_get_option_open_interest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only indicates a read operation via '[L:READ]' and a category. It lacks details on side effects, required permissions, return format, or any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but poorly structured. It uses cryptic symbols and lacks clear sentences. Important information is not front-loaded, and the format is not user-friendly.
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 name suggests a potentially complex graph related to position building, the description is severely incomplete. There is no explanation of what the graph represents, the output format, or why agent_catalog is a prerequisite. Without annotations or output schema, the description fails to provide adequate 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?
There are no parameters, so schema coverage is 100%. The description does not add parameter semantics, but with zero parameters, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague. It labels the tool as a read operation in the '账户' (account) category but does not state what 'position builder graph' means or what it does. The purpose is unclear beyond being a read operation related to accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to call agent_catalog first ('请先调用 agent_catalog'), which is a usage dependency. However, it provides no guidance on when to use this tool versus the many sibling tools, nor 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 any behavioral traits. The tag '[L:READ]' might hint at read-only behavior, but it is non-standard and not explained. There is no mention of rate limits, pagination, data scope, or whether authentication is required. The description is insufficient for an agent to understand the tool's side effects or constraints.
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 (one line), but it sacrifices clarity for brevity. It does not earn its place because it is not informative. A concise description should still be clear and actionable, which this is not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It fails to specify the return format (e.g., trade list), volume of data, or how to interpret results. The mention of 'agent_catalog' suggests a dependency that is not explained. The tool's complexity is low (1 param), but the description still leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'sprdId', and the schema already provides a description in Chinese. The tool description adds no additional semantic value beyond what the schema offers. According to guidelines, baseline is 3 for high coverage, and this description does not improve upon it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description contains a tag '[L:READ]' and a category label 'CAT:[策略-价差]', but does not explicitly state that the tool retrieves public spread trades. The name implies it, but the description is vague and does not clearly differentiate from sibling tools like 'okx_get_spread_trades'. The Chinese text '→ 请先调用 agent_catalog' adds confusion rather than 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?
The description only provides a prerequisite instruction ('call agent_catalog first') but gives no guidance on when to use this tool versus alternatives, such as the non-public version or other spread data tools. No context about authentication, data freshness, or typical use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The [L:READ] tag hints at a read-only operation, but with no annotations, this is the only behavioral clue. The description lacks details on side effects, rate limits, authentication, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with metadata. However, it is underspecified and does not effectively communicate the tool's purpose, making it barely adequate.
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 tool about financial staking offers with one optional parameter and no output schema, the description is extremely incomplete. It does not describe the return format, what constitutes an offer, or any contextual details beyond a prerequisite call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for the single parameter productId. The description adds no additional meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only contains metadata tags and an instruction to call agent_catalog first. It does not explicitly state that this tool retrieves staking offers; the purpose is implied only from the tool name. Without the name, the description is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus its many siblings (e.g., okx_get_staking_orders, okx_stake_eth). The only instruction is to call agent_catalog first, which is a prerequisite but does not help differentiate 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. The [L:READ] tag hints at read-only behavior, but this is not formal. The description only notes a prerequisite call to agent_catalog, lacking details on data nature, rate limits, or safety.
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 line with prefixes). While concise, it is unclear and uses cryptic tags that may not be universally understood, limiting its effectiveness.
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 3 parameters, no output schema, and no annotations, the description fails to explain return values, pagination, or any context about prediction candles. It is inadequate 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 100%, so the schema already documents bar, limit, and instId. The description adds no parameter meaning beyond the schema, thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes [L:READ] and CAT:[预测] suggesting a read operation for predictions, but does not explicitly state that it retrieves candlestick data for prediction markets. The purpose is unclear and requires knowledge of the category system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus many sibling tools like okx_get_candles or okx_predictions_orderbook. The instruction to call agent_catalog first is vague and does not clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes '[L:WRITE]' indicating a write operation, but no annotations are present. It does not disclose what setting fee type entails, side effects, permissions, or any other behavioral traits beyond being a write. The description does not compensate 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but contains Chinese text and cryptic tags. It is not structured for easy comprehension by an AI agent. Conciseness is present but at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and simple parameters, the description should explain what setting fee type accomplishes. It only provides a category and prerequisite, leaving the agent with incomplete context about the tool's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear enum values and descriptions in Chinese for the feeType parameter. The description adds no extra meaning, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a cryptic tag format '[L:WRITE] CAT:[账户]' and a Chinese prerequisite hint. It does not explicitly state that the tool sets the fee type, which is only discernible from the name. The purpose is not clearly communicated in English or in a standard manner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus any of the many sibling tools. The only hint is to call agent_catalog first, but no rationale or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not describe read-only nature, side effects, authorization needs, or return format. The '[L:READ]' prefix is ambiguous and insufficient.
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 but lacks substance; it consists of a cryptic prefix and a prerequisite. It is concise but at the cost of clarity and completeness, with no front-loading of the tool's 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?
For a tool with 2 optional parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the tool's function, return value, or any behavioral context beyond the prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'limit' and 'roomId'. The description adds no additional parameter semantics beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lacks an explicit verb+resource statement; it only provides metadata ('[L:READ] CAT:[系统]') and a prerequisite. The tool's purpose is vaguely implied by the name 'agent_room_view' and schema parameters (roomId, limit), but not stated.
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 clear prerequisite: '→ 请先调用 agent_catalog', instructing the agent to call agent_catalog first. This provides context, but no when-to-use vs alternatives (e.g., agent_room_send) or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral traits beyond a write indication. Annotations are absent, so the description carries full burden but fails to disclose effects, permissions, side effects, or success/failure responses. The agent gets no insight into what happens when the quote is cancelled.
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 includes metadata tags, making it concise. However, the structure is not front-loaded for agent understanding; it prioritizes internal categorization over clarifying the tool's action. Every sentence is present but not optimally arranged for agent decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no output schema and no annotations, the description should cover prerequisites, behavior, and results. It only mentions a prerequisite (call agent_catalog). Missing details on cancellation confirmation, error states, and required authorization make it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema provides basic descriptions for both parameters (RFQ ID and Quote ID). The description adds no additional meaning, so it meets the baseline of 3. No extra context is provided beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state that the tool cancels a quote. It relies entirely on the tool name 'okx_cancel_quote' to convey purpose, and instead provides metadata like write operation and category. The purpose is implied but not clearly articulated.
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 only mentions a prerequisite (call agent_catalog first) but provides no guidance on when to use this tool versus alternatives like okx_cancel_rfq or okx_cancel_batch_rfqs. No usage context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as destructiveness, authorization needs, or side effects. The '[L:WRITE]' hint suggests a write operation but is insufficient 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concise in a helpful manner. It uses cryptic labels like '[L:WRITE]' and 'CAT:[交易]' without clear structure, and does not front-load the core 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 the tool has 4 parameters and a dependency on agent_catalog, the description is severely incomplete. No information about return values, prerequisites beyond the call, or behavior is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description adds no extra meaning beyond what is in the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not clearly state what the tool does. It includes a label '[L:WRITE]' and a category 'CAT:[交易]', but fails to describe the action of closing a position. The purpose is only implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It only mentions a prerequisite ('请先调用 agent_catalog'), which is not usage context or differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. The only hint is '[L:WRITE]', which suggests a write operation, but it doesn't explain what exactly is written (e.g., order placement, account modification) or any side effects, permissions needed, or rate limits. The description is insufficient for an agent to understand 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is not effective conciseness. It omits essential information about the tool's purpose and usage. Every sentence should earn its place, but here the two fragments are insufficient to guide an agent, lacking clear structure or completeness.
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 has 6 parameters (5 required) and no output schema, the description must explain the tool's function, parameter relations, and return value. It fails to do so. The directive to call agent_catalog is a small step, but overall the description is completely inadequate 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?
The input schema has 100% description coverage for all parameters, providing clear meanings (e.g., price range, grid number, direction enums). The tool description adds no additional semantic value beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not clearly state what the tool does. It contains a category tag '[策略-网格]' (strategy-grid) and a directive to call agent_catalog first, but no verb like 'create' or 'place'. The purpose is only vaguely implied by the category and the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only provides a single usage instruction: '请先调用 agent_catalog' (call agent_catalog first). It does not specify when to use this tool versus the many sibling tools, nor does it describe any preconditions or alternatives beyond the prerequisite.
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 includes '[L:WRITE]' hinting at a write operation, but no annotations exist. It does not explain effects, permissions, or rate limits, leaving major behavioral gaps.
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?
Extremely short but underspecified; not concise in a helpful way. Lacks structure and important 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?
With 4 required parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the tool's purpose, behavior, or prerequisites beyond a vague label.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters are clearly described in the input schema. The description adds no additional meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a label ('策略-网格') and a prerequisite instruction ('请先调用 agent_catalog'), but it does not state what the tool does. The purpose is only inferred from the tool name and schema.
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. Only a prerequisite instruction to call agent_catalog first, which is minimal context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only hints at a write operation via 'L:WRITE' but does not disclose required permissions, side effects, or limitations. The description fails to inform the agent of behavioral traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one line) but poorly structured. It mixes Chinese and English with brackets, lacking clear sentences. The compactness is not an asset because it sacrifices 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?
For a tool with 5 parameters (4 required), no output schema, and no annotations, the description is woefully incomplete. It merely provides a prerequisite and a category, leaving the agent without enough context to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter descriptions (in Chinese), so the schema already documents parameter semantics. The tool description adds no additional information about the parameters. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic shorthand 'L:WRITE' and a category tag, but doesn't clearly state what the tool does. The purpose is partially inferred from the name 'create_subaccount_api_key', but the description adds no explicit verb+resource definition. The prerequisite note '请先调用 agent_catalog' distracts rather than clarifies.
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 usage guidance is '请先调用 agent_catalog', which is a prerequisite but not a when-to-use or when-not-to-use directive. No comparison with sibling tools like get, reset, or delete subaccount API keys is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only labels the tool as write operation ([L:WRITE]), but does not disclose other behavioral traits such as required permissions, side effects, rate limits, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not effectively concise. It includes obscure brackets and a directive that wastes characters. The core purpose is not front-loaded, and the brevity sacrifices 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?
Given the tool is a write operation with three required parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the tool returns, preconditions beyond calling agent_catalog, or any behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions in Chinese (e.g., '卖出数量', '买入币种', '卖出币种'). The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a category label and a reference to agent_catalog, but does not clearly state what the tool does. The name 'easy_convert' hints at a conversion operation, but the description lacks a specific verb and resource, making it hard to distinguish from other tools like okx_convert_trade.
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 says '→ 请先调用 agent_catalog' (please call agent_catalog first), implying a prerequisite, but provides no guidance on when to use this tool versus alternatives. No context for appropriate usage scenarios is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only indicates a read operation and a category, without disclosing any behavioral traits (e.g., return format, side effects, prerequisites beyond the note). This is insufficient for an agent to understand 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 very short (two lines), which is concise, but it sacrifices informativeness. It contains a prerequisite instruction and a category label, but lacks substance. It is appropriately sized for the trivial parameter count but fails to provide a meaningful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and zero parameters, the description still needs to explain what the tool returns or how it fits into the workflow. The prerequisite hint is useful, but the description is otherwise empty, leaving the agent with insufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, and schema coverage is 100%. With no parameters, the description does not add extra meaning beyond what is already in the schema, but a baseline of 4 is appropriate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name suggests retrieving account subtypes, but the description only provides a category label and a prerequisite instruction ('请先调用 agent_catalog'). It does not clearly state what the tool does with a specific verb and resource, leaving the purpose 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?
The description instructs to call agent_catalog first, but does not explain when to use this tool versus alternatives or any exclusions. The prerequisite is noted, but overall guidance is minimal.
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 indicates read-only via [L:READ] but lacks details on behavioral traits such as authorization requirements, rate limits, data freshness, or what 'block ticker' implies. Minimal disclosure beyond the read hint.
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 but at the expense of clarity. It uses cryptic notations without explanation and is not front-loaded with a plain-language purpose. The structure is poor for quick understanding.
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 simple schema (1 param, no output schema), the description is highly incomplete. It does not explain what a block ticker is, how it differs from a regular ticker, or what the output contains. Leaves the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the only parameter 'instId'. The tool description adds no extra semantic meaning beyond what the schema already provides, so baseline of 3 is appropriate.
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 uses cryptic tags (READ, CAT) and states a prerequisite (call agent_catalog) but fails to clearly state that the tool retrieves block ticker data for an instrument. The verb and resource are implied by the name but not explicitly stated in the description, making it 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?
Provides a prerequisite (call agent_catalog first) but no guidance on when to use this tool versus siblings like okx_get_ticker, okx_get_block_tickers, or other market data tools. Does not differentiate usage contexts.
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 offers minimal behavioral info beyond a read hint. It does not disclose side effects, authorization needs, or data scope, leaving the agent without critical context for a data-retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not effectively concise—it omits essential purpose and usage information. The structure (bracket prefix and prerequisite) is not front-loaded with the tool's main function.
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 large number of similar sibling tools and the lack of an output schema, the description is severely incomplete. It fails to explain what data is returned, how it differs from related tools, or how to use the parameters effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters (end, begin, instId). The description adds no extra parameter context 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague: '[L:READ] CAT:[统计] | → 请先调用 agent_catalog' does not explicitly state that the tool retrieves the contract trader long-short ratio. The purpose must be inferred from the tool name. No clear verb or resource is described.
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 instructs to call agent_catalog first, but provides no guidance on when to use this tool over its many siblings (e.g., okx_get_long_short_ratio, okx_get_top_trader_long_short_ratio). No context for selection is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers minimal behavioral insight beyond a read hint. It does not disclose any side effects, authorization needs, or other behavioral traits expected for a complete tool definition.
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 but not efficiently informative. It uses cryptic notation and Chinese that may not be universally understood. While concise, it fails to convey the tool's purpose or value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain return values or behavior. It does not. Given the large set of sibling tools and the likely complexity of the API, this description is severely incomplete, leaving the agent without enough 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?
The input schema has no parameters, and schema description coverage is 100% (vacuously). According to guidelines, baseline is 3 because no parameter information is needed. However, the description does not add context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only contains a cryptic label ('[L:READ] CAT:[账户]') and an instruction to call another tool first. The purpose is not clear from the description alone.
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 advises to call 'agent_catalog' first, which is a prerequisite, but does not specify when to use this tool versus alternatives like 'okx_get_convert_currency_pair' or 'okx_get_convert_estimate_quote'. There is no guidance on 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?
The description includes '[L:READ]' indicating a read operation, but this is not an annotation and is the only behavioral hint. Beyond that, no details about side effects, rate limits, data refresh rate, or other traits are disclosed. With no annotations, the description carries the full burden and 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line) and while technically concise, it sacrifices clarity and completeness. It fails to provide essential information, making it under-specified rather than efficiently concise.
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 tool with 3 optional parameters, no output schema, and many siblings, the description is woefully incomplete. It does not explain what the history contains, how to interpret parameters, or what the response looks like. The prerequisite instruction alone is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters (after, limit, before) described in Chinese. The description adds no additional semantic information beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague and cryptic, using a category label and a prerequisite instruction ('→ 请先调用 agent_catalog') instead of explicitly stating the tool's purpose. The name suggests it retrieves history of easy convert operations, but the description fails to confirm this or provide a clear verb-resource statement.
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 guidance is a prerequisite to call agent_catalog first, but there is no advice on when to use this tool versus alternatives like okx_get_easy_convert_currency_list or okx_easy_convert. No exclusions or context for selection are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description identifies the tool as read-only ('L:READ') and public ('CAT:[公共]'), but fails to disclose other behavioral traits such as rate limits, authentication needs, or effects on state. The brief label is insufficient 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), but it lacks crucial information. It is under-specified rather than concise; the brevity comes at the expense of clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a minimal description, the tool definition fails to explain what the tool returns or how to interpret the data. The directive to call agent_catalog implies additional context is needed, but the description itself is nearly empty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the input schema with Chinese explanations (e.g., '结束时间戳（毫秒）' for end timestamp). The description does not add additional meaning, but the schema coverage is 100%, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a label '[L:READ] CAT:[公共]' and a directive to call agent_catalog first. It does not explicitly state that the tool retrieves economic calendar events, leaving the purpose vague. The verb is implied but not articulated.
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 instructs the user to call agent_catalog before using this tool, indicating a prerequisite. However, it does not specify when to use this tool over alternatives, nor does it provide any context or 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?
With no annotations provided, the description must disclose behavioral traits. It only marks the tool as read ([L:READ]) but does not mention authentication requirements, rate limits, or what type of data is returned. The prerequisite hint 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is not effectively concise because it lacks critical information. It is more cryptic than clear, and the prerequisite instruction adds ambiguity rather than 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?
The description is severely incomplete. Given the tool has one optional parameter and no output schema, the description should explain what a funding balance is, how it differs from other balance endpoints, and what the response contains. None of this is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter description, and the tool description adds no extra meaning beyond what the schema already provides. The baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description fails to explicitly state that the tool retrieves the funding balance for OKX. Instead, it only provides a read indicator and a prerequisite instruction. The name implies the purpose, but the description itself is vague and does not clarify what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only instructs to call agent_catalog first, without explaining when to use this tool versus alternatives like okx_get_balance or okx_get_margin_balance. No differentiation from sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only hints at 'READ' (suggesting idempotency) but fails to disclose behavioral traits such as permission requirements, rate limits, or side effects. The description carries the full burden but offers minimal insight.
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?
While short, the description is under-specified and cryptic, omitting essential information. It is not concise in a useful sense; brevity without clarity is a drawback.
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 has 5 parameters, no output schema, and no annotations, the description is completely inadequate. It fails to explain return values, pagination behavior, or any other contextual details needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents parameters. The description adds no additional meaning beyond what is already in the schema, so baseline score of 3 is appropriate.
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 provides a cryptic header '[L:READ] CAT:[行情]' and instruction to call agent_catalog first, but does not clearly state the tool's action (retrieve historical index candles) or provide a meaningful verb-resource pair. The purpose is vague and requires inference.
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 okx_get_index_candles or okx_get_history_candles. The instruction to call agent_catalog is unclear and does not help with decision-making.
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 such as data retur ned, pagination, rate limits, or any side effects. The '[L:READ]' prefix hints at read-only but 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks informative content. It is underspecified rather than concise, failing to convey necessary details in an efficient manner.
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 similar sibling tools (e.g., okx_get_candles, okx_get_history_index_candles), 5 parameters, and no output schema, the description is completely inadequate. It does not specify what the tool does, how it differs, or what the return format is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already defines parameters. The description does not add any extra meaning beyond what is in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a category label '[L:READ] CAT:[行情]' and a reference to call agent_catalog, but does not explicitly state that the tool retrieves index candles. The purpose is implied by the name, but the description adds little 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 on when to use this tool versus alternatives like okx_get_candles or okx_get_history_index_candles. The instruction to call agent_catalog first is ambiguous and 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.
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 indicates read-only via '[L:READ]' and public category, but lacks details on rate limits, error conditions, or consequences of skipping the prerequisite. This minimal disclosure is insufficient for safe agent invocation.
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 (one line with meta tags and a prerequisite note). While concise in length, it lacks substantive content, making it more under-specified than efficient. Every word should earn its place, but here the brevity comes at the cost of 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?
Given the tool has no parameters, no output schema, and no annotations, the description is the sole source of context. It fails to explain what the tool returns, how it behaves, or provide any usage examples. The prerequisite instruction is present but incomplete without further guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, so schema coverage is trivially 100%. The description adds no parameter information, but none is needed. Baseline 3 is appropriate as the description does not detract but adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides meta tags ('[L:READ] CAT:[公共]') and a prerequisite note but does not explicitly state what the tool retrieves. The name suggests it deals with interest rate loan quota, but without elaboration, the purpose remains vague and fails to differentiate from siblings like okx_get_interest_rates or okx_get_max_loan.
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 instructs to call agent_catalog first, offering a prerequisite guideline, but does not specify when to use this tool versus alternatives or any contextual scenarios. No when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions a read permission tag '[L:READ]' and a category, but does not describe any behavioral traits such as authentication requirements, rate limits, or whether the tool is safe/idempotent. No side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it fails to be clear. It front-loads a prerequisite instruction instead of the tool's purpose. While brevity is good, omitting essential information makes it inadequate.
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 completely inadequate for a tool with no input schema, no output schema, and no annotations. It does not explain what MMP config is, what data the tool returns, or any expected behavior. An agent cannot understand the tool's role from this description.
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 does not need to add parameter information. The baseline for zero parameters is 4, and there is no deduction since the description does not mislead about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description fails to state what the tool does. It only provides a prerequisite instruction ('→ 请先调用 agent_catalog') and a category tag. The tool's name suggests it retrieves MMP config, but the description does not confirm this, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No contextual guidance is given for when to use this tool versus alternatives like okx_set_mmp_config or okx_reset_mmp. The description only instructs to call agent_catalog first, without explaining why or what conditions warrant using 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 carries full burden. It only has a cryptic '[L:READ]' tag possibly indicating read-only, but no explicit behavioral traits (e.g., authentication, data scope, rate limits) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but overly cryptic (tags and Chinese phrase). It lacks clear structure and the single line does not efficiently convey tool purpose or 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 the tool's complexity (copy trading domain, many sibling tools) and lack of output schema, the description is severely incomplete. It omits return value information, full prerequisites, and contextual details needed for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two optional parameters. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[策略-跟单]' and tells to call 'agent_catalog' first, but does not clearly state what the tool does. The name 'get_my_lead_history' suggests retrieving lead trading history, but the description fails to confirm this 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 indicates a prerequisite ('请先调用 agent_catalog' i.e., call agent_catalog first), but provides no guidance on when to use this tool versus alternatives like other lead/copy trading tools. No when-not or explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a label '[L:READ]' hinting at read-only behavior, but no annotations are provided. There is no disclosure of side effects, authentication needs, rate limits, or other behavioral traits. The transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is overly terse and fails to convey essential information. It includes a prerequisite that may be useful but wastes the opportunity to describe the tool's 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?
The description is severely incomplete. With no annotations, no output schema, and three parameters, the description should provide more context about the tool's return data, usage constraints, and behaviors. It only gives a prerequisite and a category.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for all three parameters. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague and does not clearly state that the tool retrieves option trades from OKX. The name is self-explanatory, but the description only provides a prerequisite ('please call agent_catalog first') and a category label, which is insufficient for purpose 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 on when to use this tool versus siblings. The only instruction is to call agent_catalog first, which is a prerequisite but not a usage guideline. Sibling tools include many other OKX public data tools, and there is no distinction.
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 labels the tool as read-only with '[L:READ]', but beyond that, there is no disclosure of behavioral traits such as side effects, authentication requirements, rate limits, or response characteristics. With no annotations, the burden is on the description.
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 but fails to be informative. It includes a cryptic label and a prerequisite command, but lacks clarity. Conciseness is not valuable at the expense of understanding.
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 (option summary) and lack of output schema, the description is completely inadequate. It does not explain what the tool returns, under what conditions, or how to interpret the data. Prerequisite alone is not sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with parameters 'uly' and 'expTime' fully described. The description adds no additional meaning, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[公共] | → 请先调用 agent_catalog' is cryptic and does not clearly state that the tool retrieves an option summary. The purpose is only weakly implied by the tool name. No verb-resource 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?
The description includes a prerequisite ('call agent_catalog first') but provides no guidance on when to use this tool versus siblings like okx_get_option_trades or okx_get_option_open_interest. No explicit use cases 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?
The tag '[L:READ]' hints at read-only behavior, but this is not formally defined as an annotation. No disclosure of rate limits, data freshness, or response structure. With no annotations, the description should carry more weight but provides minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but not useful. It wastes characters on internal tags ('[L:READ] CAT:[行情]') and a mysterious prerequisite call. Conciseness should prioritize clarity, not just 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?
With 80+ sibling tools, a clear description is critical. This description provides zero context about data returned, depth parameter usage, or how this tool differs from other order book tools. No output schema compounds the issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 2 parameters with descriptions (e.g., '深度档位，默认20，最大400'). The description adds no extra semantic value beyond the schema, but with 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just a tag '[L:READ] CAT:[行情]' and a note to call agent_catalog first. It does not state that this tool retrieves an order book. While the name 'okx_get_orderbook' is clear, the description itself fails to articulate 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 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 siblings like 'okx_get_books_full' or 'okx_get_spread_orderbook'. No prerequisites or alternatives are mentioned beyond the vague '请先调用 agent_catalog'.
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. The '[L:READ]' tag indicates a read-only operation, which is useful, but no additional behavioral traits are disclosed (e.g., what positions are returned, account scope, rate limits). This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line), which is concise, but the content is not clearly structured for an AI agent. The tags are terse but may not be universally understood. It front-loads the read hint but lacks a plain language summary.
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 optional param, no output schema), the description should at least mention what the tool returns (e.g., current positions for the account). It only provides a prerequisite, leaving the return values and context unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with an enum and description. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ] CAT:[账户]' instead of a clear statement. The name implies retrieving positions, but the description does not explicitly state the verb and resource. It is vague and relies on inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The hint '→ 请先调用 agent_catalog' provides a prerequisite but no when-to-use or when-not-to-use context. Sibling tools like okx_get_positions_history are not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only includes '[L:READ]' suggesting read-only. It does not explicitly state that the tool is safe, non-destructive, or disclose any side effects, rate limits, or required permissions.
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?
Extremely concise but at the expense of clarity. The description is a single line in Chinese with a reference to another tool. It lacks structure and front-loads no actionable information for an English-speaking agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (2 required) but no output schema. The description does not explain return values, pagination, or how the tool fits into workflows. It is insufficient for the 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 100% with descriptions for all parameters, so schema already explains parameter meaning. The description adds no value beyond schema, meeting baseline. However, no additional usage context or format guidance is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is in Chinese ('[L:READ] CAT:[公共] | → 请先调用 agent_catalog'), which does not clearly state the tool's function in English. The name suggests retrieving position tiers, but the description fails to confirm this or explain what position tiers are, leaving purpose 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 versus siblings. The only instruction ('请先调用 agent_catalog') is a prerequisite but does not differentiate usage context or provide 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; description only marks as [L:READ] and category. No details on data freshness, latency, or behavior under 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but cryptic and not informative. The structure uses markers that are not explained.
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 or annotations; description fails to explain what the ratio represents or how to interpret results. Highly incomplete given the complexity of options data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions; description adds no extra parameter meaning. Baseline 3.
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 is vague; includes category and prerequisite but does not explicitly state that it retrieves the put/call ratio. The name suggests the function but the description lacks 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?
Includes a prerequisite ('call agent_catalog first') but no guidance on when to use this vs. sibling tools like okx_get_open_interest or okx_get_option_oi_ratio.
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 behavior. It only includes '[L:READ]' (possibly indicating read-only) and a category, but does not describe side effects, authentication needs, rate limits, or any behavioral traits beyond the implied 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is in Chinese, uses symbols, and lacks structure. While concise, it under-specifies the tool's purpose and behavior, making it less helpful for an AI agent.
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 lack of output schema, the tool's complexity (signal bots), and the minimal description, the description is severely incomplete. It does not explain return values, pagination, connection to agent_catalog, or any other contextual details needed for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents both parameters (algoId, instType). The description adds no additional meaning beyond the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name suggests retrieving pending signal bots, but the description ('[L:READ] CAT:[策略-信号] | → 请先调用 agent_catalog') is vague and in Chinese. It does not clearly state what the tool does or what 'pending' means, relying heavily on 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?
The description provides a prerequisite ('call agent_catalog first'), which is a usage guideline, but it does not explain when to use this tool over siblings or alternatives. No context on appropriate 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 provided, the description carries full burden. It only indicates a read operation via '[L:READ]' but does not disclose behavioral traits such as what happens on invalid algoId, rate limits, or side effects. The precondition is noted but 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which can be seen as concise, but it sacrifices clarity. The use of tags is structured, but the lack of natural language makes it less readable. Every symbol earns its place, but the overall value is low.
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 one required parameter and no output schema or annotations, the description is incomplete. It does not explain the return value, how to interpret results, or any important context beyond the precondition. The agent lacks sufficient information for correct invocation.
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 100% and the schema already describes the parameter. The tool description adds no additional meaning or context to the parameter beyond what the schema provides. No usage hints or format details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ] CAT:[策略-信号]' but does not state in plain language that the tool retrieves positions for a signal bot. The purpose is implied from the name and tags, but lacks a clear verb+resource statement.
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 a precondition ('请先调用 agent_catalog') but does not provide guidance on when to use this tool versus sibling signal tools like okx_get_signal_positions_history or okx_get_signal_sub_orders. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 includes a non-standard '[L:READ]' prefix hinting at read-only behavior, but does not disclose other behavioral traits such as required permissions, data scope, or side effects. The description adds minimal value 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to convey sufficient information. While it is front-loaded with the READ prefix, it does not earn its place because it omits essential details about the tool's function. It is under-specified rather than concise.
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 moderate complexity (no output schema, no annotations, many sibling tools), the description is critically incomplete. It does not explain what sub-orders are, how they relate to signal bots, or what the response contains, leaving the agent without necessary 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 100% with both parameters described, so baseline is 3. The description does not add any additional meaning or context beyond what the schema provides, so no extra credit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It only provides a category label and a prerequisite, relying on the tool name to imply purpose. This is vague and insufficient for an AI agent to understand the 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 only mentions a prerequisite to call 'agent_catalog' first, but does not explain when to use this tool versus other signal-related sibling tools (e.g., okx_get_signal_orders, okx_get_signal_positions). No context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only hints at being read-only via '[L:READ]' but fails to describe any side effects, permission requirements, or return behavior. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), but it lacks completeness. Conciseness is not achieved when essential information is missing. It should be more verbose 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?
With no output schema and zero parameters, the description should clearly state what the tool returns (e.g., SOL staking balance). It does not. The instruction to call agent_catalog adds confusion without context. The tool is critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and 100% schema description coverage. The description adds nothing beyond the schema, but since parameters are absent, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague, only providing a category and a reference to call agent_catalog. It does not explicitly state that the tool retrieves SOL staking balance, relying on the tool name. This is barely above a tautology.
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 instructs to call agent_catalog first but does not explain when to use this tool versus alternatives like okx_get_sol_staking_history or okx_get_eth_staking_balance. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It only hints at read-only via '[L:READ]', but provides no details on rate limits, error handling, or response format. Behavioral expectations remain unclear.
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 but underspecified. It fails to convey the tool's function in a helpful way, prioritizing brevity over clarity. Not an example of effective conciseness.
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 tool with 5 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain what the tool returns, how pagination works, or how to interpret results. Complete inadequacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters are documented in the input schema with descriptions, achieving 100% coverage. The description adds no extra meaning, but the schema already explains each parameter. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[行情] | → 请先调用 agent_catalog'. It does not clearly state that this tool retrieves historical candles for a spread contract. The purpose is only vaguely inferable from the tool name and parameter schema.
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 instructs to call 'agent_catalog' first, but gives no context on when to use this tool versus siblings like 'okx_get_spread_candles' or 'okx_get_candles'. No comparison or selection criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It indicates a read operation via '[L:READ]' but does not disclose any other behaviors such as pagination, return format, or what happens when no parameters are supplied. The description is minimal and inadequate for a tool with 4 optional parameters.
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 but not well-structured. It uses cryptic codes and Chinese without clear English explanation. Conciseness should aid clarity, but here it sacrifices understanding. The structure is fragmented and not front-loaded with a clear tool 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 4 parameters, no output schema, and many sibling spread tools, the description is highly incomplete. It does not explain what a 'spread' is in this context, how it differs from other spread tools, what the output will look like, or any constraints. The agent would struggle to use 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 description coverage is 100%, so the baseline is 3. The description does not add any extra meaning beyond the schema descriptions. Since the schema already describes each parameter in Chinese, the description provides no additional value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[策略-价差]' and Chinese text. It vaguely indicates a read operation related to spreads but does not clearly state 'Get spreads' or explain what the tool does in plain English. This is insufficient for an agent to understand the purpose, especially compared to sibling tools with clearer names like okx_get_spread_ticker.
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 instruction '请先调用 agent_catalog' provides a prerequisite step, which is useful, but there is no guidance on when to use this tool versus the many sibling spread tools (e.g., okx_get_spread_ticker, okx_get_spread_orderbook). The agent is left to infer usage without differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates '[L:READ]' suggesting read-only behavior, but lacks details on side effects, authorization needs, or rate limits. The description is too minimal to disclose meaningful 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks substance. It uses cryptic labels and a prerequisite note without explaining what the tool does. Conciseness is not achieved when critical information is omitted.
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 (wide range of sibling tools, 2 parameters, no output schema), the description is woefully incomplete. It fails to specify return values, the scope of trades (recent, historical, public), or any usage details. The agent cannot effectively use this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes the parameters. The description adds no additional meaning beyond what is already in the schema (e.g., 'instId: 产品ID', 'limit: 返回条数，默认20'). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not clearly state what the tool does. It only includes a category label and a prerequisite instruction ('请先调用 agent_catalog'). The purpose must be inferred from the name 'okx_get_trades', which is insufficient for distinguishing it from sibling tools like okx_get_ticker or okx_get_history_trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only notes that agent_catalog should be called first, but does not explain the context or when to choose this tool over similar ones like okx_get_trades_history or okx_get_orderbook.
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 labels the tool as '[L:WRITE]' indicating a write/mutation operation, but does not disclose side effects, required permissions, error conditions, or order lifecycle details (e.g., confirmation, partial fills). This is inadequate for a trading tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to convey essential information. It uses cryptic tags and a Chinese prerequisite. Brevity is not beneficial when it omits core purpose and usage details. Every sentence should earn its place; here, the two fragments do not adequately describe the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of placing a spread order (5 parameters, no output schema, no annotations), the description is entirely incomplete. It does not explain what a spread order is, how parameters interact, or what return values to expect. The reliance on a separate tool (agent_catalog) further fragments 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?
The input schema has 100% description coverage for all 5 parameters, including enums and types. The description adds no extra meaning beyond the schema; it simply restates the category and prerequisite. Since the schema already documents parameters well, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague: it includes '[L:WRITE] CAT:[策略-价差]' indicating a write operation and strategy-spread category, but does not explicitly state that the tool places a spread order. The name 'okx_place_spread_order' implies the purpose, but the description fails to confirm or elaborate, making it unclear for an agent.
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 '请先调用 agent_catalog' (call agent_catalog first) as a prerequisite, providing minimal usage guidance. However, it offers no comparison to sibling tools like okx_place_order or okx_place_algo_order, nor does it specify when to prefer this tool over alternatives. The guidance is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must entirely convey behavioral traits. It fails to disclose any details such as required permissions, idempotency, side effects, or return behavior of the cancellation. The tag '[L:WRITE]' hints at mutation but provides no substantive behavioral insight.
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?
While the description is very short, it lacks a structured explanation of the tool's function. It is more underspecified than concise, with essential information missing. The tag and prerequisite are presented without clear organization or complete sentences.
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 mutation tool with no output schema, the description must provide sufficient context about cancellation behavior, state changes, and response format. It completely fails to do so, leaving the agent with insufficient information 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 100% with one parameter 'orderId' described as '订单ID'. The description adds no additional meaning beyond the schema, which already defines the parameter. Baseline 3 is appropriate as the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description contains only a tag '[L:WRITE] CAT:[预测]' and an instruction to call agent_catalog first. It does not explicitly state that this tool cancels an order, relying solely on the tool name to convey purpose. The purpose is vague and not clearly articulated.
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 instruction '请先调用 agent_catalog' provides a clear prerequisite, indicating that the agent should first retrieve the catalog before using this tool. However, it offers no guidance on when to use this tool over alternatives like okx_predictions_cancel_all or okx_event_cancel_order, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only indicates read-only via '[L:READ]' but does not explain data freshness, rate limits, or any side effects. The description is too minimal for an agent to understand 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse (one line) but sacrifices clarity for brevity. It contains cryptic labels and non-English text, which may be confusing. It is not well-structured for quick comprehension.
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 annotations, the description should provide comprehensive context about return values, behavior, and usage. It fails to do so, leaving agents without critical information to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (sz and instId) having descriptions in the schema. The tool description adds no additional meaning beyond these, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description contains cryptic labels '[L:READ] CAT:[预测]' and a directive to call agent_catalog, but fails to clearly state the tool's function. The name suggests retrieving a predictions orderbook, but the description does not clarify this or differentiate from sibling tools like okx_get_orderbook or outcomes_get_orderbook.
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 ('请先调用 agent_catalog'), implying the tool should not be used directly without prior context. However, it provides no guidance on when to use this tool versus alternatives (e.g., okx_get_orderbook) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives only a '[L:WRITE]' tag indicating a write operation, which is already obvious from the tool name. It does not disclose behavioral traits such as authentication requirements, rate limits, order lifecycles, or side effects beyond the basic write nature.
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 but at the cost of informativeness. It consists of a single line with tags and a prerequisite, lacking structure or clear separation of information. Conciseness should not sacrifice essential content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, write operation, many siblings) and absent output schema, the description is severely incomplete. It does not explain what happens after placing an order, return values, or how the order is managed. This is inadequate 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage of all 5 parameters with descriptions, so the description is not required to add parameter details. However, the description adds no additional semantic context or examples beyond the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides category tags and a prerequisite instruction ('请先调用 agent_catalog'), but does not explicitly state what the tool does (e.g., places an order for prediction markets). The tool name implies placement, but the description is vague and lacks a clear verb+resource statement.
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 (calling agent_catalog), which provides some guidance, but there is no information on when to use this tool versus alternatives like okx_event_place_order or other order placement tools. It fails to differentiate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects (e.g., whether it mutates state), authentication needs, or rate limits. The '[L:READ]' prefix is ambiguous and may even mislead about the tool's mutating nature.
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 but lacks clarity and is not front-loaded with a clear purpose. The cryptic notation and dependency instruction waste the limited space, failing to efficiently convey the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter set, the description should provide more context about what resetting MMP does, its prerequisites, and potential impacts. The current description is incomplete and leaves the agent underinformed.
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 'instFamily' has a schema description ('产品族，如 BTC-USD。必填') that provides a concrete example and notes it is required. With 100% schema coverage, the description adds meaningful context beyond the schema itself, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic ('[L:READ] CAT:[交易] | → 请先调用 agent_catalog'), offering no explicit statement of the tool's purpose. The tool name 'okx_reset_mmp' suggests resetting Market Maker Protection, but the description fails to clarify this, relying on the name alone.
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 'okx_set_mmp_config' or 'okx_reset_rfq_mmp'. The description only mentions calling 'agent_catalog' first, but does not explain usage 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 provided. The description is minimal and does not disclose behavioral traits such as whether the operation is destructive, requires authentication, or has side effects. The admin tag hints at privilege but 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the cost of clarity. It is a single line with tags and a prerequisite, lacking structure for effective AI agent use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is woefully incomplete for a tool that changes account configuration. No output schema, no explanation of effects, no error conditions, and no context on implications of different account levels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'acctLv' having a description in Chinese explaining the enum values. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only contains a Chinese tag indicating admin level and account category, and instructs to call agent_catalog first. It does not state that the tool sets the account mode (simple/margin types), relying on the parameter enum to infer 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?
The description gives a prerequisite (call agent_catalog first) but no guidance on when to use this tool vs siblings like okx_set_leverage or okx_set_position_mode.
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, and the description only contains a write tag and a category label. It does not disclose effects, permissions, rate limits, or return behavior, leaving the agent blind to the tool's implications.
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 but fails to be informative. Conciseness without clarity is not helpful. The structure uses tags but does not effectively convey 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 complex domain and numerous sibling tools, this description is completely inadequate. It does not differentiate from similar tools like okx_stop_copy_trader, nor does it explain what 'stop copy trading' means or what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (no parameters), so baseline is 3. The description adds no parameter-related value, but since there are no parameters, the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags and Chinese text that does not clearly state the tool's purpose. It hints at 'copy trading' and 'strategy' but lacks a clear verb and resource. The instruction to call agent_catalog first only adds 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 mention of agent_catalog is a prerequisite but does not help the agent decide when to invoke this tool among many copy-trading 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?
The description labels the tool as read-only ([L:READ]), but the name implies a write operation (unstake), potentially misleading. No details on side effects or outputs.
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?
Extremely short but not well-structured; uses cryptic tags and lacks clarity. Not front-loaded with essential 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?
Description fails to convey the tool's core functionality or context. No output schema, and the prerequisite is not explained. Completely inadequate for a single-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 coverage is 100%, and the parameter 'amt' has a schema description. The tool description adds no further meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explain what the tool does. It only indicates a category and a prerequisite, relying on the tool name to infer purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Only states to call agent_catalog first, which is a prerequisite, not a usage comparison.
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 whether the tool is destructive, what authentication is needed, or any side effects. A close operation should at minimum indicate that it terminates the connection, but the description omits this entirely.
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 wastes characters on non-informative tags and a Chinese note. It could be more concise and front-loaded with a clear action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 'close' operation, the description should clearly state the action, prerequisites, and any return values. It only hints at a prerequisite (agent_catalog) and fails to explain the core function, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with one optional parameter described in the schema. The tool description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ] CAT:[行情-WS]' and a Chinese prerequisite note, but never explicitly states that this tool closes a WebSocket connection. The purpose is vague and relies on interpreting the tool name and categorization.
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 advises calling 'agent_catalog' first, which is a usage guideline, but it offers no comparison to sibling WebSocket tools (e.g., okx_ws_subscribe, okx_ws_unsubscribe) or guidance on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It hints at a read operation via '[L:READ]' but discloses no other behavioral traits such as return format, required permissions, or rate limits. The instruction to call agent_catalog is not about behavior but a prerequisite.
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?
While extremely concise, the description lacks essential information about the tool's purpose and functionality. Proper conciseness would front-load key details; instead, it is under-specified and unhelpful.
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 name suggests a non-trivial operation (checking arbitrage), the description is completely inadequate. It does not explain return values, when to use, or any behavioral details. No output schema or annotations exist 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?
The schema coverage is 100% for the single parameter 'marketId' with description '市场ID，必填'. The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[预测] | → 请先调用 agent_catalog' is cryptic and does not clearly state the tool's function. The name 'outcomes_check_arbitrage' suggests checking arbitrage in outcomes markets, but the description fails to elaborate, leaving the purpose 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?
The description only instructs to call 'agent_catalog' first, which is a prerequisite. It provides no guidance on when to use this tool over the many sibling tools like 'outcomes_list_events' or 'okx_predictions_ticker', thus lacking usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only marks the tool as read via '[L:READ]' but fails to mention pagination, side effects, or rate limits. The behavior is largely inferred from 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but poorly structured. It uses cryptic labels and a non-English directive without front-loading the core purpose. It sacrifices clarity for brevity, making it under-specified.
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 tool with 3 parameters, no output schema, and many similar sibling tools, this description is critically incomplete. It does not explain return values, scope (e.g., 'events' of what type), or how it differs from other list/search 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 each parameter already has a description. The tool description adds no additional parameter context, but the schema is sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic ('[L:READ] CAT:[预测] | → 请先调用 agent_catalog') and does not clearly state the verb and resource. It hints at a read operation on predictions but provides no explicit 'list events' purpose. The tool name 'outcomes_list_events' gives more clarity than the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The phrase '请先调用 agent_catalog' suggests a prerequisite but does not explain when to use this tool versus alternatives like 'okx_predictions_list_events' or 'okx_predictions_search_events'.
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. The description hints at a write operation with '[L:WRITE]' but does not clarify side effects, authorization requirements, rate limits, or return behavior. The prerequisite hint 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line) but lacks clarity and proper structure. It uses cryptic tags and does not front-load a clear purpose. It is under-specified rather than concise.
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 a JSON-RPC call tool with no output schema, the description is severely incomplete. It does not explain the tool's function, return values, or usage, and the prerequisite instruction is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'method' and 'params' parameters. The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It includes a cryptic label '[L:WRITE]' and category 'CAT:[链上]' but fails to explain that this tool performs JSON-RPC calls to the Xlayer blockchain. The purpose is only implied by the tool name and input schema.
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 says 'call agent_catalog first', which is a prerequisite but does not help an agent choose between this and sibling tools like xlayer_get_events or xlayer_subscribe.
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 marks the tool as a write operation ('L:WRITE') and notes a prerequisite, but does not explain side effects, permissions, or what changes occur when amending copy settings.
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 but cryptic, using brackets and symbols. It is not structured for clarity and reads more like an internal note than a user-facing explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a write operation with no output schema, the description should explain return values or effects. It lacks completeness, only providing a prerequisite and write indicator. No behavioral or outcome details are given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions. The description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'L:WRITE' and 'CAT:[策略-跟单]' suggests a write operation for copy trading strategy, but does not explicitly state what 'amend copy settings' does. It is vague and relies on the tool name for 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 includes a prerequisite '请先调用 agent_catalog' (call agent_catalog first), but provides no guidance on when to use this tool versus other copy trading tools like okx_set_copy_settings or okx_first_copy_settings.
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, and the description fails to disclose any behavioral traits (e.g., if it cancels orders, whether it is destructive). The [L:WRITE] label hints at it being a write operation but is not part of the descriptive text.
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 overly minimal and lacks structure. It consists of a label and a prerequisite instruction, which is underspecification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain return values, side effects, or what happens when the timer triggers. For a write tool, this is insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'timeOut', which is well-described in Chinese. The description adds no additional information beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a label and a reference to another tool. The purpose is inferred from the input schema parameter 'timeOut', but the description itself is 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?
The description only instructs to call agent_catalog first, but gives no guidance on when to use this tool versus sibling cancel tools like okx_cancel_order or okx_cancel_all_rfqs.
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. The [L:WRITE] label hints at a write operation, but there is no disclosure about destructive effects, rate limits, or what happens upon cancellation. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but cryptic and not front-loaded with purpose. It uses non-English labels without explanation, making it inefficient for an agent to parse meaning quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of batch cancelling RFQs, the description is incomplete. It lacks details on return values, error handling, or prerequisites beyond the vague 'call agent_catalog'. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the rfqIds parameter clearly (JSON array of IDs). The tool description adds no additional parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic, using labels like [L:WRITE] and CAT:[策略-RFQ] without clear explanation. It does not explicitly state that this tool cancels multiple RFQs, instead implying a prerequisite call to agent_catalog. This obscures the core 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 only mentions a prerequisite ('请先调用 agent_catalog'), which provides a minimal usage hint. However, it fails to compare with sibling tools like okx_cancel_rfq or okx_cancel_all_rfqs, and does not explain when to use this batch version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as a write operation but provides no additional behavioral details such as authentication requirements, side effects, or reversibility. With no annotations, the description carries the full burden and 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but unclear and cryptic. It wastes the opportunity to convey purpose and guidance. Conciseness should not sacrifice clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the trading system and the lack of output schema, the description is inadequate. It does not specify return values, error handling, or the effect of cancellation, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the input schema with Chinese labels, but the description adds no further meaning. Since schema coverage is 100%, the baseline score is 3, and the description does not improve on it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a category label and a reference to agent_catalog, but does not explicitly state that the tool cancels an order. The name implies the purpose, but the description fails to confirm it clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like okx_cancel_all or okx_batch_cancel_orders. The description does not mention 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 carries full burden but only conveys that it is a write operation ('[L:WRITE]'). It fails to disclose critical behavioral traits such as order type (market/limit), whether it executes immediately, required permissions, or potential side effects like affecting balances.
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?
While short, the description is under-specified rather than concise. It lacks essential information, making it unhelpful. Every sentence should add value, but here the single line does not adequately summarize the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and the tool performs a complex action (trade), the description should explain expected return values or confirmations. It does not address what the agent should expect after invocation, leaving significant gaps for a trading operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents the three parameters (sz, toCcy, fromCcy) clearly. The description adds no additional semantic value beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague; '[L:WRITE] CAT:[账户]' does not clearly state that the tool performs a currency conversion trade. The schema implies conversion, but the purpose is not explicitly articulated, barely distinguishing it from sibling convert tools like okx_convert_contract_coin or okx_convert_currency_pair.
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 only provides a prerequisite ('请先调用 agent_catalog') but no guidance on when to use this tool versus alternatives such as okx_get_convert_estimate_quote or okx_get_convert_currencies. It lacks 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?
No annotations are provided. The description only tags the tool as a write operation but does not disclose side effects, idempotency, rate limits, or other behavioral traits beyond the basic write indication.
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 brief but also cryptic, sacrificing clarity for brevity. It lacks a clear front-loaded purpose statement and uses ambiguous formatting.
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 fails to provide essential context such as return values, success/failure indicators, or invocation prerequisites beyond calling agent_catalog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description. The tool description adds no further meaning to parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags ('[L:WRITE]', 'CAT:[策略-RFQ]') and a prerequisite note, but does not explicitly state that the tool creates a Request For Quote (RFQ). The purpose is implied by the name but not clearly articulated.
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 instructs to call agent_catalog first, providing a prerequisite. However, there is no guidance on when to use this tool versus alternatives like okx_create_quote 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 provided; description carries full burden. Indicates write operation via '[L:WRITE]' but discloses no side effects, authentication needs, rate limits, or success/failure behavior. Leaves agent unaware of the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, but at the cost of clarity. The instruction to call agent_catalog is efficiently placed, but lacks explanatory sentences about the tool's function. Could be improved with brief context.
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?
Tool is a creation action with two required parameters and no output schema. Description fails to explain what a signal bot is, what channel/signalName mean, expected result, or error states. Incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with basic descriptions for channel and signalName. Description adds no further semantics; baseline 3 is appropriate since schema already documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is cryptic with tags like '[L:WRITE] CAT:[策略-信号]' instead of explicitly stating the tool creates a signal bot. The instruction '→ 请先调用 agent_catalog' implies a prerequisite but does not clarify what the tool itself does. Relies heavily on the tool name for 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?
Only provides a single prerequisite ('call agent_catalog first'). No guidance on when to use this tool vs siblings like okx_stop_signal_bot or okx_get_signal_bots_pending. No scenarios 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 must disclose behavioral traits. It only mentions category and prerequisite, with no info on idempotency, destructiveness, return value, or side effects. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line) and includes a category tag and prerequisite. However, it sacrifices completeness for brevity. It is front-loaded with useful hints but lacks structure.
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 incomplete for a tool with 4 parameters, no output schema, and many siblings. It does not explain the return value, usage context, or effect. The prerequisite agent_catalog is mentioned but not explained. This is inadequate.
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 100% coverage with parameter descriptions. The description adds no additional meaning to parameters. It does not elaborate on how parameters interact or any constraints beyond the schema. Baseline for high coverage is 3, but since description adds no value, score is reduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description labels the tool as WRITE and category '策略-跟单' but does not explicitly state what the tool does. The name 'first_copy_settings' implies initial setup, but the description lacks a clear verb and resource. It is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite directive '请先调用 agent_catalog', which is a useful guideline. However, it fails to distinguish when to use this tool versus sibling tools like okx_set_copy_settings. No when-not-to-use or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It only indicates a read operation via '[L:READ]' but lacks details on authentication, rate limits, output format, or side effects. No contradictions since annotations are absent.
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 but uses a cryptic format that is not self-explanatory. It is under-specified, lacking clarity in favor of 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?
No output schema is present, so the description should hint at return values or behavior. It only provides a prerequisite (call agent_catalog) without explaining what the tool returns or how it fits into the broader workflow. Inadequate for a 2-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters (ordType, instType) with enums and Chinese descriptions. The tool description adds no additional meaning beyond the schema. Given high coverage, baseline is 3, but the description could have added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[交易-委托]' but does not explicitly state that the tool retrieves algo orders. It fails to distinguish from sibling tools such as 'okx_get_orders_algo_pending' or 'okx_get_algo_orders_history', making the purpose 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?
The description only instructs to call 'agent_catalog' first, but does not explain when to use this tool versus alternatives like 'okx_place_algo_order' or 'okx_get_algo_orders_history'. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It adds '[L:READ]' for read-only hint but lacks details on authentication, rate limits, or response format. The tag format is non-standard and incomplete.
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 terse (one line with tags) but lacks a clear sentence structure. It sacrifices clarity for brevity, making it hard to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, the description should clearly state the tool's core function. It fails to do so, relying on the name and cryptic tags. The reference to 'agent_catalog' is unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100%—both 'lang' and 'annType' have descriptions. The description adds no extra parameter semantics beyond the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a cryptic tag format ('[L:READ] CAT:[公共] | → 请先调用 agent_catalog') instead of a clear statement. The tool's purpose is implied by its name and parameters, but the description does not explicitly say 'get announcements from OKX'.
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 hints at a prerequisite ('call agent_catalog first') but provides no guidance on when to use this tool over alternatives. No explicit when/when-not or sibling comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers minimal behavioral info beyond the read hint in the title. It does not mention rate limits, required permissions, or what happens when ccy is empty.
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?
While very short, the description is not effective: it uses a cryptic format and incomplete sentences, wasting the opportunity to be clear. It is under-specified rather than 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?
With no output schema and no annotations, the description is insufficient. It omits return format, pagination, and any error handling details, leaving the agent without enough 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 parameter 'ccy' is well-described in the input schema ('指定币种，不填返回全部'), covering 100% of the parameter. The tool description adds no new semantic value, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[资金] | → 请先调用 agent_catalog'. It does not clearly state that the tool retrieves asset balances; the purpose is only inferable from the tool name. It lacks a direct verb and resource statement.
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 note '请先调用 agent_catalog' hints at a prerequisite but does not explain the context or exclude scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only gives a read hint but no details on auth, rate limits, or behavior. The description fails to compensate 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is too short and lacks substance; it is a tag and a prerequisite note, not a proper description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema, the description fails to explain what bills are, what is returned, or any operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. Description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only provides a read tag and a prerequisite note. 'Bills' is ambiguous without context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only says to call agent_catalog first, but gives no guidance on when to use this tool vs alternatives like okx_get_account_bills.
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 hints at read-only behavior via '[L:READ]'. It omits details on authentication, rate limits, side effects, or data scope, leaving the agent underinformed.
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 but fails to front-load essential purpose information. It uses cryptic tags and a reference to another tool, sacrificing clarity 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 absence of an output schema and parameter details, the description should explain the content of the history. It does not, leading to ambiguity, especially with similar sibling tools present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0), and schema description coverage is 100%. The description adds no parameter information, which is acceptable since there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses tags like '[L:READ]' and 'CAT:[账户]' but does not explicitly state what 'borrow repay history' entails. It relies on the tool name for meaning, which is insufficient for clear understanding.
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 'okx_borrow_repay' or 'okx_get_one_click_repay_history'. The only instruction is to call 'agent_catalog' first, which is a prerequisite, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It labels the tool as read-only via '[L:READ]', which is a behavioral trait, but lacks details on rate limits, authentication, data scope, or effects. The description is insufficient for an AI agent to understand usage behavior.
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 but cryptic, using non-standard shorthand and Chinese tags. It lacks clear structure and does not efficiently convey meaning, sacrificing clarity 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 absence of an output schema and a minimal description, the tool remains poorly specified. The 3 parameters are documented but the return value and exact data (contracts taker volume) are not explained. Sibling tools exist but are not differentiated; the tool feels incomplete 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 100% with descriptions for all three parameters (ccy, begin, end) in Chinese. The description adds no additional parameter context beyond the schema. Baseline is 3 due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[统计]' which vaguely hint at readonly and statistics, but does not explicitly state that the tool retrieves taker volume for contracts. The purpose is unclear without interpretation, and it fails to distinguish from siblings like 'okx_get_taker_volume' or 'okx_get_taker_flow'.
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 prerequisite ('→ 请先调用 agent_catalog'), indicating a need to call 'agent_catalog' first, but offers no guidance on when to use this tool versus alternatives, nor mentions 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 carries the full burden. It only includes a cryptic '[L:READ]' hint (likely read-only) but does not explicitly confirm safety or disclose any behavioral traits like rate limits, permissions, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the cost of clarity. It is not front-loaded with useful information; instead it contains vague tags and a prerequisite call. The conciseness is harmful rather than helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple parameter and no output schema, so complexity is low. However, the description is insufficient: it does not explain what the tool returns or how to use it correctly, and the prerequisite to call agent_catalog is unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 a single parameter 'ccy' with a description already in Chinese (currency, e.g. USDT, required). Schema coverage is 100%, so baseline is 3. The description adds no additional semantic value beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[资金] | → 请先调用 agent_catalog'. It does not clearly state that this tool retrieves a lightning deposit address. The purpose is only inferable from the name and parameter, but the description is minimal and ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The only hint is '请先调用 agent_catalog' (please call agent_catalog first), but it does not explain why or when this is necessary, nor does it distinguish from sibling deposit/withdrawal tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only indicates a read operation and public category. It does not disclose authentication needs, rate limits, return values, or other behavioral traits beyond the minimal read hint.
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 short but cryptic, using abbreviations and a prerequisite instruction that does not explain the tool itself. It is not front-loaded with a clear purpose statement, and the structure is confusing.
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 complexity, the description should explain what the tool returns and when it is useful. It lacks any explanation of the output or the context in which to use the estimated price, relying on a reference to agent_catalog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter `instId` with a clear example and requirement. The description adds no additional meaning, but schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a read label and category but does not explicitly state what the tool does. The tool name suggests it retrieves an estimated price, likely for options, but the description is cryptic and fails to 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 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 includes a prerequisite to call agent_catalog, but does not help the agent decide when to invoke this tool over sibling tools like okx_get_ticker or okx_get_instruments.
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 labels the tool as '[L:READ]' implying read-only behavior, which is useful context not in annotations. However, it does not disclose other important behavioral traits such as authentication requirements, rate limits, potential side effects (though read-only suggests none), or what data is retrieved. The transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single line with tags. While it is concise, it sacrifices clarity for brevity. The use of mixed languages (Chinese and English) and cryptic prefixes reduces its effectiveness, though it is well below the size limit.
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 has 3 parameters, no output schema, and no annotations, the description should provide substantial context about what grid AI parameters are, typical usage, and expected return format. It provides none of this. The note to call agent_catalog suggests a dependency but does not explain how. The description is completely inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters have descriptions in the input schema (e.g., instId, direction, algoOrdType). The description adds no extra meaning beyond these schema descriptions. Per guidelines, baseline is 3 when schema coverage is high, and the description does not improve parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a cryptic label '[L:READ] CAT:[策略-网格]' which indicates read-only and a category of 'strategy-grid', but does not clearly state in plain language what the tool does. The name 'okx_get_grid_ai_param' suggests retrieving AI parameters for grid trading, but the description fails to confirm this purpose explicitly. It is vague and relies on domain knowledge.
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 a prerequisite instruction '→ 请先调用 agent_catalog', which tells the agent to call agent_catalog first. However, it provides no guidance on when to use this tool versus the many sibling tools (e.g., okx_get_grid_orders_pending, okx_create_grid_order). No alternative tools or context for selection are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. '[L:READ]' suggests read-only, but this is self-declared and not validated. No mention of side effects, rate limits, or other behavioral traits beyond the read hint.
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?
Very short but unnecessarily cryptic with brackets and Chinese. The directive to call agent_catalog first is useful but the format is poor; not front-loaded with clear 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?
No output schema and the domain (grid orders) is complex. Description lacks explanation of what is returned (e.g., list of pending orders, fields). The tool seems to require a prerequisite but does not complete the picture for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes all three parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline for high coverage.
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 uses cryptic prefixes '[L:READ] CAT:[策略-网格]' and Chinese directive instead of a clear English statement. The tool name suggests 'get pending grid orders' but the description does not explicitly confirm this. Distinguishing from sibling grid order tools (e.g., okx_get_grid_orders_history) is not addressed.
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?
Only guidance is '→ 请先调用 agent_catalog', which is a prerequisite but does not explain when to use this tool versus alternatives like okx_get_grid_orders_history or okx_get_grid_sub_orders. No context on 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only hints at a read operation via '[L:READ]' but does not disclose important behavioral traits such as pagination, rate limits, or any side effects. The lack of output schema further reduces transparency.
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 (one line) but fails to convey essential information. Conciseness should not come at the cost of clarity. The cryptic prefix and lack of complete sentences make it poorly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the tool's moderate complexity (3 required params), the description is incomplete. It does not explain what the tool returns, the result format, or when it should be used. 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 100% and each parameter has a description in the input schema (though in Chinese). The tool description does not add additional meaning beyond what the schema provides, which is acceptable given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic ('[L:READ] CAT:[策略-网格]') and does not explicitly state what the tool does. The name suggests retrieving grid sub-orders, but the description lacks a clear verb+resource. It relies on abbreviations and Chinese without explaining the operation.
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 only provides a precondition ('请先调用 agent_catalog'), but no guidance on when to use this tool versus sibling tools like okx_get_grid_orders_pending or okx_get_grid_orders_history. No rationale for selection is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only indicates 'L:READ' but does not disclose other behavioral traits such as rate limits, authentication, data freshness, or pagination behavior. This is insufficient for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified and does not provide useful information. Conciseness should not come at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, many siblings) and lack of output schema, the description is very incomplete. It does not differentiate from similar tools or explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds no additional meaning, but the baseline is 3 given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state the tool's purpose. It only includes a category tag and a prerequisite instruction. The tool's function must be inferred from its name, which is insufficient for clear purpose 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 given on when to use this tool versus alternatives like okx_get_mark_price_candles or okx_get_candles. The instruction to call agent_catalog is a prerequisite, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only includes a read hint. It does not disclose any behavioral traits such as authentication needs, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but cryptic, containing a fragment that confuses more than it informs. It is not front-loaded with useful 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 simple parameter and no output schema, the description is incomplete. It does not explain the tool's return value or how to interpret the result, requiring the user to call 'agent_catalog' first without context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, and the description adds no extra meaning beyond the schema's documentation for 'instId'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and does not clearly state what the tool does. It includes a label '[L:READ]' and a note to call 'agent_catalog' first, but lacks a verb and resource. The name 'get_index_price' gives some hint, but the description fails to 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 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 like 'okx_get_index_tickers' or 'okx_get_ticker'. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only provides cryptic tags and does not disclose behavioral traits like read-only nature (though '[L:READ]' hints), permissions, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not informative. It uses non-standard tags and fails to convey purpose, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and a cryptic description, the tool is poorly documented. It lacks explanation of return values and prerequisite (agent_catalog).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (one parameter with enum and description). The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic with tags like '[L:READ]' and 'CAT:[公共]', and a directive to call agent_catalog. It does not clearly state that the tool retrieves instrument tick bands for options, nor does it distinguish from sibling tools like okx_get_instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The instruction '请先调用 agent_catalog' is vague and does not explain 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 provided. The description only implies a read operation via '[L:READ]' but does not disclose side effects, authentication needs, or other behavioral traits expected from a financial data 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 extremely concise but not structured as a proper description. It is a cryptic note that fails to convey the tool's functionality clearly, making it under-specified rather than efficiently 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?
With three optional parameters, no output schema, and no annotations, the description does not provide sufficient context about return values, data format, or how to interpret the results, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three optional parameters (e.g., '币种，如 USDT'). The tool description adds no additional information beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. The name suggests it gets accrued interest, but the description is cryptic with '[L:READ] CAT:[账户]' and an instruction to call agent_catalog first, which is not a clear statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The only hint is to call agent_catalog first, but no context on use cases or exclusions among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only has a '[L:READ]' tag (not official) and a category flag. It doesn't mention authentication, rate limits, or data scope. The prerequisite is noted but insufficient 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but it is not effectively concise because it misses critical functional details. It reads as a note rather than a proper description, wasting the opportunity to inform the agent.
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 annotations; the description should cover what the tool returns and any prerequisites. It only mentions calling agent_catalog, but the rest of the context (e.g., return format, filtering) is absent. Incomplete for a tool with 2 parameters and a required one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides. It does not explain how the parameters affect the results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does explicitly. It contains a category hint and a prerequisite note but lacks a clear verb+resource statement. The name suggests 'lead trader positions' but the description relies on that implicit understanding.
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 only mentions calling agent_catalog first but gives no guidance on when to use this tool versus alternatives like okx_get_my_lead_positions. No context on when to use or avoid 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?
The description includes '[L:READ]' hinting at read-only behavior, but lacks details on what data is returned (e.g., current leverage, max leverage), error handling, or any side effects. With no annotations, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but cryptic, sacrificing clarity for brevity. The prerequisite note is not front-loaded with the main purpose, and the format is not user-friendly for an AI agent.
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 indicate what the tool returns (e.g., leverage info). It only provides a prerequisite, leaving the return value and typical usage incomplete. Important context 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%, and the schema already provides clear descriptions for both parameters ('instId' and 'mgnMode'). The description adds no extra semantic value, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'CAT:[账户]' and prerequisite note do not clearly state that this tool retrieves leverage information for an instrument and margin mode. The purpose is vague and relies on the tool name for understanding.
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 calling 'agent_catalog' first, providing a prerequisite, but offers no guidance on when to use this tool instead of alternatives like 'okx_set_leverage' or 'okx_get_positions'. No contextual differentiation.
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 includes '[L:READ]' which suggests read-only, but does not mention authentication, rate limits, or what happens if parameters are invalid. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, with only two fragments, but it lacks substance and structure. It is under-specified, using cryptic brackets and Chinese without clear formatting. Not an example of effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should explain the return value and context for use. It does not, leaving agents without enough information to properly invoke the tool or 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 description coverage is 100%, so the input schema already documents the parameters (instId and mgnMode) with descriptions. The tool description adds no additional parameter semantics, but the schema is sufficient. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses '[L:READ] CAT:[账户]' which hints at a read operation for account margin balance, but it is too vague and does not clearly state the tool's function beyond what the name implies. It lacks specificity and fails to distinguish it from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs '请先调用 agent_catalog' as a prerequisite, but provides no guidance on when to use this tool versus alternatives like okx_get_balance or other account tools. No differentiation or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavior. The [L:READ] tag hints at a read operation, but does not explain side effects, required permissions, or response format. The description is insufficient for a public API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks informativeness. It prioritizes conciseness at the expense of clarity, and does not effectively front-load the tool's purpose. More detail is needed for a 2-parameter 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 complexity of the OKX API and many sibling tools, the description fails to complete the context. It does not explain that this tool retrieves mark prices, nor differentiate it from similar tools. The prerequisite instruction is useful but not sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters (instId and instType). The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags ([L:READ], CAT:[公共]) and a prerequisite instruction, but does not explicitly state that the tool retrieves mark prices for given instrument types. The purpose is vaguely implied by the tool name, but the description adds no 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 on when to use this tool versus alternatives like okx_get_mark_price_candles or okx_get_instruments. The only instruction is to call agent_catalog first, which is a prerequisite, 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.
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 hints at a read operation via '[L:READ]' but does not mention side effects, permissions, or return data. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but omits necessary information, making it cryptic rather than concise. It fails to be informative 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?
Given no output schema and many sibling tools, the description should explain what a monthly statement is and how it differs from related tools. It does not, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% trivially. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[资金] | → 请先调用 agent_catalog' is cryptic; it indicates a read operation and a category but does not clearly state what the tool does. 'Monthly statement' from the name is not elaborated, making it vague for an agent.
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 okx_get_account_bills. The note '请先调用 agent_catalog' suggests a prerequisite but does not provide usage 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 provided, the description carries the full burden. It only labels the tool as read-only (L:READ) but fails to disclose rate limits, data scope, or any behavioral traits 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but the content is not informative. The directive to call agent_catalog first is tangential, and the overall conciseness does not serve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and the description does not explain what the returned data represents. Given the simplicity of the tool, more context about return values or typical usage 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?
Schema coverage is 100%, so the baseline is 3. The description does not add any additional meaning or constraints beyond what is already in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lacks a clear verb and resource; it only directs to call agent_catalog without indicating that this tool retrieves open interest. The purpose is inferred from the name, but the description adds no value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings like okx_get_open_interest_history. The description does not differentiate usage contexts or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only adds '[L:READ]' implying read-only, but does not elaborate on auth needs, rate limits, or other behavioral traits. The prerequisite dependency is mentioned but insufficient.
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?
While extremely short, it lacks substance and does not earn its place; it is under-specified rather than concise. Every sentence should contribute, but here the description is minimal and uninformative.
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 three parameters, no output schema, and no annotations, the description should compensate but fails to explain purpose, return values, or behavior. Only mentions a prerequisite call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter; the description adds nothing beyond the schema. Baseline of 3 is appropriate since schema already documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Only has '[L:READ]' and 'CAT:[统计]' which hint at permissions and category, but does not state what the tool does. The name implies retrieving open interest history, but the description itself is missing a clear verb and 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 like 'okx_get_open_interest'. The only direction is to call agent_catalog first, which is a prerequisite, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only hints at read-only via '[L:READ]', but does not disclose authentication needs, rate limits, error behavior, or any side effects. For a read operation, basic behavioral details 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes non-standard prefixes and a seemingly mandatory prerequisite call, which adds noise and reduces clarity. It is not concise in a helpful way.
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 the tool ecosystem (many sibling order tools), no output schema, and no annotations, the description is far from complete. It fails to explain return values, error cases, or how this tool fits into the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (ordId and instId). The description adds no further meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes cryptic tags like '[L:READ] CAT:[交易]' and an instruction to call agent_catalog, but does not clearly state that the tool retrieves a specific order by ID. The name is self-explanatory, but the description adds confusion rather than 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 on when to use this tool versus other order retrieval tools like okx_get_orders_pending or okx_get_orders_history. The only instruction is to call agent_catalog first, which is a prerequisite but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only indicates it's a read operation via '[L:READ]' but does not disclose any behavioral traits such as what constitutes an 'algo' order, whether it returns active or historical orders, or any side effects. More context is needed for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concise in a helpful way. It uses cryptic tags and a conditional instruction, which is poor structure. The message '请先调用 agent_catalog' could be front-loaded but the overall lack of clarity makes it ineffective.
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 low complexity (1 parameter, no output schema, no nested objects), the description should clarify what an order algo is and what data it returns. It fails to do so, leaving the agent without essential context about the tool's function or output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'algoId' described as '策略委托ID' (strategy order ID). Schema coverage is 100%, so the description adds no new meaning beyond the schema. The baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic labels '[L:READ] CAT:[交易]' without defining what the tool does. It says to call 'agent_catalog' first, but doesn't explain the purpose of 'okx_get_order_algo' itself. The name suggests retrieving algorithmic orders, but the description fails to confirm this or provide 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 sibling tools. The only usage hint is '请先调用 agent_catalog', which is a prerequisite, not a usage guideline. There is no mention of when to use this vs other order-related tools like 'okx_get_algo_orders' or 'okx_get_order'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only indicates a read operation via '[L:READ]', but lacks details on rate limits, data scope, or any other behavioral traits. This is minimal disclosure.
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 line with tags), but it is under-specified. It sacrifices informativeness for brevity, which is not effective.
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 that there is no output schema and the tool retrieves potentially complex historical orders, the description fails to specify what data is returned or any important context like pagination or filtering. It is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its two parameters (limit and instType), so the description does not need to add extra meaning. The baseline of 3 is appropriate as the schema already documents parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a tag format '[L:READ] CAT:[账户]' which implies it's a read operation for accounts, but does not explicitly state that it retrieves orders history. The name itself is clear, but the description adds little value.
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 a prerequisite note '→ 请先调用 agent_catalog' indicating that agent_catalog should be called first, but it provides no guidance on when to use this tool versus alternatives like okx_get_order or okx_get_orders_pending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only includes a read hint and category, omitting details such as rate limits, permissions, or behavior when no pending orders exist.
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 but incomplete. It lacks essential information about the tool's function, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should explicitly state that the tool retrieves pending orders. It fails to do so, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions. The tool description adds no extra meaning, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It only provides a category and a directive to call another tool. The name suggests pending orders, but the description is vague and does not confirm 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (call agent_catalog first) but gives no guidance on when to use this tool versus siblings like okx_get_orders_history or okx_get_orders_pending (spread). No alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. The '[L:READ]' hint suggests a read operation, but no further behavioral details (e.g., side effects, rate limits, required permissions) are disclosed. The description is insufficient for an agent to understand the tool's full behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one line) but not effectively concise. It omits essential information and relies on cryptic tags. While not verbose, it fails to be informative, which reduces usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter and no output schema, the description should explain what price limit data is returned and possibly the format. It does not, leaving the agent without enough context to use the tool properly. This is incomplete even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full coverage for the sole parameter 'instId' with a clear description. However, the tool description adds no additional meaning beyond the schema, so it does not improve the parameter semantics. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[公共] | → 请先调用 agent_catalog' does not explicitly state the tool's purpose. It hints at being a public read operation and suggests a prerequisite, but the core action (getting price limits) is only inferred from the tool name. This is vague and lacks a clear verb-resource statement.
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 prerequisite ('请先调用 agent_catalog') but offers no guidance on when to use this tool versus alternative sibling tools (e.g., okx_get_ticker, okx_get_orderbook). There is no mention of when not to use it or what scenarios it is designed for.
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 to indicate traits like read-only or destructive behavior. The '[L:READ]' tag is informal and not part of the standard annotation set. The description lacks details on return format, safety, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no fluff, but it is excessively terse and lacks critical information. It is efficient but not well-structured for comprehension.
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 the tool ecosystem (many sibling copy-trading tools) and the absence of an output schema, the description is severely inadequate. It does not explain what the tool returns or how it relates to other profit-sharing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, so the description adds no extra value. The schema already documents the 'instType' parameter with its enum values. Baseline score maintained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state the tool's purpose; it only provides a category and a prerequisite. The name suggests retrieving profit sharing totals, but without differentiation from siblings like 'okx_get_profit_sharing_details'.
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 ('agent_catalog' should be called first) but offers no guidance on when to use this tool versus alternatives. There is no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It indicates a read operation via [L:READ] but does not disclose other behavioral traits such as permissions, rate limits, or side effects. The instruction to call agent_catalog implies a prerequisite but 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but its cryptic format and non-standard prefixes reduce clarity. It is not well-structured for an AI agent to parse and understand the tool's 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?
No output schema is provided, and the description does not explain the tool's return value or behavior. The prerequisite to call agent_catalog is mentioned but not justified, leaving the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (instId) described in Chinese. The description adds no additional meaning beyond the schema, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic prefixes ([L:READ] CAT:[公共]) and a Chinese instruction to call agent_catalog, but does not explicitly state what the tool does. The name suggests getting public block trades, but the description does not confirm this, leaving the purpose 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?
The only guidance is to call agent_catalog first, but it does not explain when to use this tool versus alternatives. With many sibling trade-related tools (e.g., okx_get_trades, okx_get_block_ticker), no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only indicates the tool is read-only and public, but does not disclose potential behavioral traits such as authentication requirements, rate limits, or side effects. The minimal description leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but overly cryptic, using tags and a Chinese instruction that may not be immediately understandable. It front-loads the read/public hint but lacks clear structure and substantive content, making it less effective than a simple English statement.
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 what settlement history is, how to interpret results, and any constraints. The minimal description does not adequately compensate for these gaps, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 all parameters are described in the input schema. However, the descriptions are in Chinese (e.g., '标的指数'), which may reduce clarity for non-Chinese speakers. The tool description adds no additional parameter information beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and does not clearly state the tool's purpose. It includes a tag '[L:READ] CAT:[公共]' and instructs to call 'agent_catalog' first, but does not explicitly say that the tool retrieves settlement history. The name provides a strong hint, but the description fails to confirm or explain the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description vaguely suggests a prerequisite ('→ 请先调用 agent_catalog') but does not provide clear guidance on when to use this tool versus alternatives. Among many sibling tools for similar historical data, no differentiation is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only includes a custom label '[L:READ]' which hints at read-only behavior but is not standard. There is no disclosure of side effects, rate limits, or other behavioral traits beyond the basic read hint.
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 but omits essential details about the tool's purpose and behavior. Conciseness is only beneficial if the content is sufficient; here 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 lack of annotations and output schema, the description should provide more context about return values, pagination, or typical use cases. The current description is insufficient for an agent to fully understand the tool's usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (100% coverage), so the baseline is 3. The description adds no additional information about the parameters beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a category tag and a prerequisite but does not explicitly state that the tool retrieves signal event history. The purpose is vaguely implied by the name, but the description lacks a clear verb+resource statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like okx_get_signal_subscriptions or okx_get_signal_orders. The only indication is a prerequisite to call agent_catalog first, but no context on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The tag '[L:READ]' hints at read-only behavior, but no details on side effects, permissions, or data freshness are given. This is insufficient for safe tool invocation.
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 brief, but it sacrifices essential information for brevity. It is not well-structured as it combines a tag, category, and prerequisite instruction without clear separation.
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 at least indicate the nature of returned data (e.g., list of positions with timestamps). It fails to do so, leaving the agent uninformed about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions, so the schema itself provides meaning. The description adds minimal value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is minimal, providing only a tag '[L:READ]' and a category label, but fails to explicitly state that the tool retrieves historical positions for a signal bot. The name is somewhat self-explanatory, but the description does not clarify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool relative to siblings like okx_get_signal_positions or okx_get_signal_bots_history. The instruction to call agent_catalog first is a prerequisite but does not help with 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?
Annotations are absent; the description only has '[L:READ]' indicating read-only. No mention of data freshness, permissions, rate limits, or other behavioral traits. The description carries full burden but adds minimal transparency beyond the read hint.
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?
Very short, but cryptic and includes non-English. It is concise but not effectively structured for clarity. The prerequisite call instruction adds value but the overall message is unclear.
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?
Tool is complex (spread orderbook with depth) and has many siblings, yet the description lacks explanation of what a spread orderbook is, how depth works, or how it differs from okx_get_spread_books. No output schema, so description should compensate but fails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional parameter meaning. Baseline of 3 is appropriate as the schema already describes the two parameters adequately.
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 is cryptic: '[L:READ] CAT:[策略-价差]' does not clearly state the tool's purpose. It hints at reading spread orderbook but lacks an explicit verb+resource statement. Additionally, it tells to call another tool first, confusing 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only guideline is '→ 请先调用 agent_catalog', which is minimal and does not explain when to use this tool over siblings like okx_get_spread_books or okx_get_orderbook. No 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?
No annotations are provided, so the description must disclose behavioral traits. It hints at read-only ('L:READ') but does not explicitly confirm no side effects. Missing details on authentication, rate limits, or any other behavioral considerations.
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 but poorly structured for readability. It uses non-standard formatting (brackets, arrows) that may confuse an agent. It sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description should clarify what 'pending' means in this context (e.g., unexecuted orders). It fails to explain the scope or default behavior, leaving gaps despite 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 already describes the sprdId parameter as 'spread contract ID' (100% coverage). The tool description adds no additional context about the parameter, so it meets the baseline of 3 without enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags ('L:READ', 'CAT:[策略-价差]') and does not explicitly state the tool's purpose. It fails to clearly indicate that this tool retrieves pending spread orders, leaving the agent reliant on the name alone.
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 a prerequisite ('please call agent_catalog first') but provides no guidance on when to use this tool versus siblings like okx_get_spread_orders or okx_get_spread_orders_history. No context on filtering 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 are provided, so the description carries the full burden. It indicates a read operation via '[L:READ]', which is helpful, but lacks details about any side effects, permissions, or data returned. For a read tool, minimal behavioral info is given.
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 but not clear or well-structured. The use of tags and a precondition without explanation makes it cryptic. True conciseness requires clarity, which is missing here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of many sibling spread tools, the description should clarify what a ticker represents and how this tool differs from others (e.g., orderbook, trades, candles). The output schema is absent, so the description should at least hint at return format. It fails to provide sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter 'sprdId' has an example in its description. The tool description does not add any additional semantic value beyond what's in the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags '[L:READ] CAT:[策略-价差]' and a precondition '→ 请先调用 agent_catalog', but does not clearly state that the tool retrieves the ticker for a specific spread. The purpose can be inferred from the tool name and the parameter description, but the description itself is 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 versus alternatives like okx_get_spreads, okx_get_spread_orderbook, or other spread tools. The only instruction is to call agent_catalog first, which is a prerequisite rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '[L:READ]' tag hints at read-only behavior, but with no annotations provided, the description should disclose other traits like authentication, rate limits, or side effects. It does not, leaving significant behavioral uncertainty.
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 does not waste words. However, it lacks a clear purpose statement, so the conciseness comes at the cost of completeness. It could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many sibling spread tools, no output schema, two parameters), the description is grossly incomplete. It fails to explain what the tool returns, when to use it, or how it differs from alternatives, leaving the agent without crucial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the two parameters, so the description does not need to add parameter details. It adds no extra meaning beyond the schema, fitting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description consists only of tags ('[L:READ]', 'CAT:[策略-价差]') and a prerequisite note. It does not explicitly state that the tool retrieves spread trades, leaving the agent to infer purpose from the tool name alone.
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 guidance is to call agent_catalog first. No information is given about when to use this tool versus alternative spread tools (e.g., okx_get_spread_ticker, okx_get_spread_orderbook), failing to differentiate among many similar 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 carries the full burden. It only gives a read hint but does not disclose any behavioral traits, side effects, or data characteristics 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is cryptic and not effectively concise. The structured format with brackets and Chinese text may confuse an AI agent. It does not efficiently communicate the tool's 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 lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns or how to interpret the APY data, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema description coverage is 100%. The description adds no additional meaning beyond what the schema provides, but the baseline is 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state the tool's purpose clearly. It includes a read hint and a category, but no verb or resource describing what it does. The tool name suggests it gets stable rewards APY, but the description is vague and fails to confirm this.
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 calling agent_catalog first, which is a prerequisite, but provides no guidance on when to use this tool versus other similar tools like okx_get_stable_rewards_product or okx_get_lending_rate_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description adds '[L:READ]' which may indicate read-only, but it is non-standard and insufficient. No disclosure of behavioral traits like data freshness, pagination, or error conditions beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but cryptic and inefficient. Uses brackets and Chinese text with no clear structure. It sacrifices clarity 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?
No output schema is provided. The description does not explain return values, pagination, or behavior. Referencing agent_catalog suggests missing context. The tool definition is incomplete 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 100% with descriptions for all three parameters. The tool description does not add any parameter-specific meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[金融] | → 请先调用 agent_catalog'. It hints at a read operation and a category but does not clearly state that this tool retrieves staking orders. The purpose is vague and requires prior knowledge.
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 okx_get_staking_offers or okx_get_staking_active_orders. The only instruction is to call agent_catalog first, which is a prerequisite, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool is read-only via '[L:READ]' and notes a prerequisite, but does not explain what happens if the prerequisite is not met, whether the API key is returned in plain text, or any other behavioral traits (e.g., authentication needs, rate limits). This is insufficient for a safe and informed invocation.
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 (one line), but this brevity is due to omission rather than efficiency. It lacks essential information such as a clear purpose statement and detailed behavior. The structure includes a category tag and prerequisite, but it does not earn its place because it fails to provide a complete picture.
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 (no annotations, no output schema, many sibling tools with overlapping names), the description is incomplete. It fails to explain what the tool returns, how to interpret the result, or how it differs from similar subaccount tools. The prerequisite note is a helpful hint, but overall the description leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (the only parameter, subAcct, is described in the schema as '子账户名称。必填'). The tool description adds no additional parameter information. According to the rules, when schema coverage is high, baseline is 3. The description does not improve or detract from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only includes a category tag and a prerequisite note, but does not explicitly state what the tool does. The agent must infer from the name 'okx_get_subaccount_api_key' that it retrieves a subaccount's API key, making the purpose vague and relying on the tool name rather than the description.
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 ('请先调用 agent_catalog') but provides no guidance on when to use this tool versus sibling tools like okx_get_subaccount_list or okx_get_subaccount_balance. There is no explanation of the tool's specific role within the subaccount context, leaving the agent without clear usage 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 provides minimal behavioral information. '[L:READ]' hints at a read operation, but there is no mention of authentication requirements, rate limits, or potential side effects. The prerequisite is noted, but overall transparency is lacking.
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, but it is cryptic and uses unclear codes ('[L:READ]', 'CAT:'). This brevity sacrifices clarity, making it less helpful than a well-structured, plain-language description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what the tool returns. It does not. It also omits any error information or usage context beyond the prerequisite, making it incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'subAcct' as required and provides a Chinese description. Since schema coverage is 100%, the description does not add any extra meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It uses cryptic codes like '[L:READ]' and 'CAT:[账户-子账户]' and only mentions a prerequisite ('请先调用 agent_catalog'), leaving the main function unclear. The tool name suggests retrieving subaccount assets, but the description fails to confirm this.
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 its many siblings. The only instruction is a prerequisite to call agent_catalog, but it does not clarify under what circumstances this tool is appropriate or when alternatives should be chosen.
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 such as read-only behavior, authentication requirements, or rate limits. The READ tag is non-standard and insufficient.
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 but poorly structured for an English-speaking AI. It mixes tags, Chinese text, and a prerequisite note without clear formatting. The information is dense but not effectively communicated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple balance query, but the description lacks information about return format, error handling, or any output. The prerequisite is noted but not explained. No output schema exists, so more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'subAcct', and the schema description (Chinese) defines its purpose. The tool description adds no further meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is mostly in Chinese and does not clearly state its purpose in English. It includes a READ tag and a category, but the function is only implied by the tool name. The prerequisite note '请先调用 agent_catalog' adds confusion rather than 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?
The description mentions a prerequisite ('call agent_catalog first') but provides no guidance on when to use this tool versus siblings, such as okx_get_subaccount_trading_balance or okx_get_balance. No exclusions or alternatives 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?
With no annotations provided, the description carries the full burden. The '[L:READ]' tag hints at read-only behavior, but there is no disclosure of side effects, authentication requirements, error conditions, or output format. Behavioral traits are largely absent.
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 but uses non-standard markers and Chinese text that may reduce clarity for an English-speaking AI agent. While concise, it lacks clear structure and readable sentences.
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 one optional parameter, no output schema, and no annotations. The description does not explain return values, and the prerequisite instruction is vague. It leaves significant gaps for an agent to understand the tool's full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional boolean parameter. The description adds no extra meaning beyond the schema, so baseline 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state the tool's purpose; it uses cryptic tags like '[L:READ]' and 'CAT:[账户-子账户]' and a Chinese instruction to call agent_catalog first, leaving the actual function to be inferred from the tool name. It relies on the name 'get_subaccount_list' to convey meaning.
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 only provides a single instruction to call agent_catalog first, which is a prerequisite. It lacks guidance on when to use this tool versus sibling tools like okx_list_subaccounts or okx_get_subaccount_balance, and does not indicate 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?
The '[L:READ]' tag hints at read-only behavior, but no annotations are provided. The description does not disclose other behavioral traits such as data freshness, rate limits, or side effects, leaving the agent uninformed.
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 (one line with tags), which is under-specified rather than concise. It lacks essential information about the tool's function and usage.
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, and with 4 parameters, the description fails to explain the tool's behavior, return value, or differentiation from numerous sibling tools. The prerequisite is noted but not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with 100% description coverage, so the description adds no additional semantics beyond what the schema already provides. The prerequisite is not parameter-related.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a tag '[L:READ]' to indicate a read operation and 'CAT:[统计]' for category, but does not explicitly state what the tool does. The tool name suggests retrieving taker flow for contracts, but the description lacks a clear purpose statement.
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 prerequisite ('→ 请先调用 agent_catalog'), but does not explain when to use this tool versus alternatives, nor does it specify any contextual conditions 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. The '[L:READ]' tag implies read-only, but no details on rate limits, authorization needs, or side effects are given. The description does not add substantial behavioral context beyond the inferred 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is under-specified rather than concise. The instruction to call agent_catalog first is a necessary dependency hint, but the description lacks substantive content. It could be more informative without adding length.
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 moderate complexity (contract ID, time range), no output schema, and no annotations, the description should explain return value format and behavior. It only provides a minimal category tag and a prerequisite, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear parameter descriptions (e.g., instId, begin, end as milliseconds). The description adds no additional meaning to the parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'CAT:[统计]' hints at a statistics category but does not explicitly state the tool's purpose (e.g., 'Get top trader long/short ratio for a contract'). It is not a tautology but remains vague, and fails to distinguish from many similar sibling tools like okx_get_long_short_ratio.
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 instruction '→ 请先调用 agent_catalog' is a prerequisite, not usage context or exclusion criteria. Missing when-not-to-use and alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only includes a '[L:READ]' label implying it's a read operation, but does not disclose other behaviors like authentication needs, rate limits, or side effects. The description is insufficient for an agent to understand the tool's behavioral profile.
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 (one line) but under-specifies the tool. It is front-loaded but lacks substance. Every sentence should earn its place, but here the content is too sparse to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the output of the tool, even though there is no output schema. With 3 parameters and no output specification, the description leaves the agent uncertain about what the tool returns. The prerequisite hint does not compensate for the lack of result 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 100%, with each parameter described in the input schema. The tool description adds no extra information beyond the schema, so the baseline score of 3 is appropriate. It neither improves nor degrades the understanding of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. The name 'okx_get_top_traders_contract_ls_ratio' hints at retrieving top traders' contract long/short ratio, but the description only contains a read label, category, and a prerequisite instruction. It does not differentiate this tool from similar siblings like 'okx_get_long_short_ratio' or 'okx_get_contracts_long_short_ratio'.
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 only directive is '请先调用 agent_catalog' (call agent_catalog first), which is a prerequisite but not usage context. No when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The [L:READ] tag indicates read-only behavior, which is good, but no annotations exist to supplement. The description does not disclose other behavioral traits such as side effects, authentication needs, rate limits, or response format. For a batch 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 extremely concise (one line with tags and a note), but the lack of clear purpose and context makes it feel underspecified rather than efficient. It is front-loaded with tags but sacrifices clarity 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?
Given the tool has 3 parameters, no output schema, and no annotations, the description is highly incomplete. It does not explain return values, limitations on batch size, or how the indicators are computed. The note to call agent_catalog outsources essential context, making the definition inadequate standalone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters (instId, indicators, bar). The description adds no extra meaning beyond the schema. With high schema coverage, a baseline of 3 is appropriate; the description does not degrade or enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses tags [L:READ] and CAT:[行情] but does not state a clear verb+resource. It relies on the name 'okx_indicator_batch' to imply batch indicator queries, but the text only directs users to call agent_catalog first, leaving the primary action ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite instruction ('请先调用 agent_catalog') but offers no guidance on when to use this tool versus alternatives like okx_indicator (singular) or okx_get_candles. There is no comparison or when-not-to-use info.
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 includes '[L:READ]' hinting at read-only behavior, but no annotations are provided to reinforce this. There is no disclosure of behavioral traits such as required authentication, rate limits, or side effects. The description lacks specificity about what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but at the expense of clarity. It is front-loaded with symbols that are not self-explanatory. While brevity is valued, the description should be informative. It earns a 3 as it is minimally adequate but not well-structured for an agent.
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 parameters and no output schema, the description still fails to explain what the tool does or what its output represents. The instruction to call 'agent_catalog' first suggests a prerequisite, but the overall purpose and behavior are not covered. The description is incomplete for an agent to use this tool effectively.
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 no properties, so baseline is 4 per instructions. The description does not add parameter information, but since there are no parameters, no additional clarification is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and fails to state what the tool does. It includes symbols like '[L:READ]' and 'CAT:[账户]' which are not explained, and the main content instructs to call 'agent_catalog' first, leaving the actual function unclear. The tool name 'precheck_delta_neutral' suggests a pre-check for delta neutral strategies, but the description does not confirm this.
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 prerequisite ('请先调用 agent_catalog'), which is a form of usage guidance, but it does not explain when to use this tool versus alternatives. There is no context for deciding to invoke this tool over sibling tools, and the 'when-not' scenarios are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only indicates a write operation ('L:WRITE') with no details on side effects, permissions, or state changes. The agent is left uninformed about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but at the cost of clarity. Every sentence is present but provides minimal useful information. Not an example of effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a merge operation with no output schema and no annotations, the description is severely incomplete. It does not explain merging mechanics, return values, or any behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter 'amount' with schema describing it as required string. Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'L:WRITE CAT:[预测] | → 请先调用 agent_catalog' is vague. It signals a write operation and category 'predictions' but does not specify what 'merge' does (e.g., combine prediction outcomes, merge data). The verb+resource 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 'okx_predictions_split'. The instruction 'call agent_catalog first' hints at a prerequisite but does not explain the context or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description hints at a fund transfer but does not disclose behavioral traits such as permissions, reversibility, or effects beyond the transfer.
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, but it is under-specified rather than concise. It lacks critical information to be considered efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a fund transfer in predictions) and lack of output schema, the description is insufficient. It fails to explain the redeem action or 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?
The schema has 100% coverage for the single parameter 'assetId', with a Chinese description '资产ID'. The description adds minimal value beyond the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'FUND_TRANSFER' and '预测' (predictions), but does not clearly state what the tool does. The purpose is vague, requiring inference from 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?
It instructs to call 'agent_catalog' first, providing a prerequisite. However, it lacks guidance on when to use this tool versus alternatives like other prediction or transfer 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 includes a read hint ([L:READ]) and public category, but without annotations, the burden is on the description to disclose behavioral traits. No additional behaviors (rate limits, pagination, response format) are mentioned. It is insufficient for an agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line) but it is not structured as a clear purpose statement. It reads more like an internal note than a description for an AI agent. While brevity is valued, the content is insufficient and lacks 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?
Given the tool has 2 parameters and no output schema, the description should explain what results to expect and how the search works. The current description does not differentiate this tool from many similar market data tools, leaving the agent without enough context for correct selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no extra meaning beyond the schema, so it remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only mentions it's a read operation and public, but does not explicitly state that the tool searches for instruments by keyword and instrument type. The tool name suggests the purpose, but the description itself is vague and does not clarify the 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 instructs to call agent_catalog first, which is a usage hint, but it does not provide guidance on when to use this tool versus alternatives like okx_get_ticker or okx_get_instruments. The context signals show many sibling tools for market data, and no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose behavioral traits such as whether this action is destructive, requires admin privileges, or has side effects. The prerequisite hint is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but wastes space on a prerequisite note that is not fully explained. It lacks clarity and does not efficiently convey the tool's 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 no annotations and no output schema, the description should compensate by explaining the behavior and context. It fails to do so, leaving the agent with insufficient information to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'ccy' described as 'settlement currency, e.g., USDT. Required.' The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is in Chinese and does not explicitly state the tool's action. It only provides a category and a prerequisite, leaving the main purpose (setting settlement currency) implied from the parameter name 'ccy'. This is vague and requires prior knowledge.
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 calling 'agent_catalog' first, hinting at a prerequisite, but provides no guidance on when to use this tool vs alternatives or what context it serves. Sibling tools are numerous but not differentiated.
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 bears full burden for behavioral disclosure. It indicates read-only via '[L:READ]', but lacks details on behavioral traits such as rate limits, authentication needs, or side effects. The description provides minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but under-specified. It is not efficiently meaningful; conciseness should not sacrifice clarity. The single line provides insufficient information, earning a low 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 no output schema and the tool's likely complexity (detailed trader info), the description fails to convey return structure or behavior. The prerequisite to call agent_catalog is vague. Overall incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter types and descriptions in the schema. The description adds no additional semantic value beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic ('[L:READ] CAT:[Smart Money]') and does not explicitly state what the tool does. It implies reading details of a smart trader but fails to articulate the core function, making it unclear for an agent to understand the tool's 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 advises to call agent_catalog first, providing some prerequisite context, but no guidance on when to use this tool versus alternatives like okx_smart_leaderboard. Without explicit usage scenarios, the agent may misuse the 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?
The description indicates a write operation ('[L:WRITE]') but fails to disclose behavioral details such as whether the action is irreversible, what happens to associated orders, or authentication requirements. With no annotations, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but cryptic and not well-structured. It uses tags and Chinese without clear English explanation, making it inefficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is incomplete. It does not explain the return value, side effects, or error scenarios. The prerequisite is mentioned but overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter. The description adds the prerequisite hint about calling 'agent_catalog', implying where to obtain the 'algoId', which is a marginal improvement over the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic metadata like '[L:WRITE]' and 'CAT:[策略-网格]' but does not explicitly state that the tool stops a recurring plan. The tool name provides a hint, but the description is insufficient for an agent to quickly understand the 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 instructs to call 'agent_catalog' first, which is a prerequisite, but it does not specify when to use this tool versus alternatives like 'okx_create_recurring_plan' or 'okx_get_recurring_orders_pending'. No explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only includes '[L:READ]' which may hint at read-only behavior but is not explicitly stated. There is no disclosure of side effects, permissions, rate limits, or any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the cryptic tags and Chinese instruction reduce clarity. Conciseness should not come at the expense of informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is insufficient. It fails to describe what data is returned, error conditions, or any other contextual details that would help an agent understand the tool's usage and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'marketId' described in Chinese. The description does not add any further meaning or context beyond what is in the schema, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[预测]' without clear meaning. The tool name 'outcomes_get_market' suggests getting a market, but the description does not explicitly state the function or distinguish it from siblings like 'outcomes_get_event' or 'outcomes_list_markets'.
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 instructs to call 'agent_catalog' first, indicating a prerequisite, but provides no guidance on when to use this tool versus alternatives or what scenarios it is best suited for.
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. The description includes '[L:READ]' suggesting read-only behavior, but does not elaborate on what data is returned, rate limits, or any side effects. This minimal transparency is insufficient for an agent to fully understand 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but cryptic (using non-English tags) and lacks self-contained meaning. While it is concise, it sacrifices clarity, making it hard for an agent to interpret without additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with 2 parameters and no output schema, the description fails to explain what the tool returns or how it differs from similar tools. The prerequisite pointer to agent_catalog is useful but not enough; the overall context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters are described in Chinese (marketId: '市场ID', outcome: '结果方向'). The description adds no additional meaning beyond the schema. Baseline 3 applies because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and non-English. It does not explicitly state that the tool retrieves a ticker (price/status) for a prediction market outcome. The name implies it, but the description fails to clarify. It only provides metadata-like tags and a prerequisite instruction.
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 instructs to call agent_catalog first, indicating a prerequisite, but offers no guidance on when to use this tool versus siblings like outcomes_get_market or outcomes_get_orderbook. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. Despite being an 'unsubscribe' operation (likely destructive), the description includes '[L:READ]' which misleadingly suggests a read-only operation. There is no mention of side effects, authorization requirements, or confirmation of success.
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 brief but sacrifices clarity for conciseness. It uses non-standard tags and a Chinese sentence that does not efficiently convey the tool's purpose or usage. Every part should add value, but here it is cryptic.
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 one required parameter and no output schema, the description should explain prerequisites (e.g., getting a subscriptionId from xlayer_list_subscriptions) and the effect of unsubscribing. It only mentions calling agent_catalog without connecting the dots, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the sole parameter 'subscriptionId' with a Chinese description meaning 'subscription ID to cancel'. With 100% schema coverage, the baseline is 3. The description adds no additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and does not explicitly state that the tool is for unsubscribing from a subscription. It includes non-standard tags like '[L:READ]' and 'CAT:[链上]' which do not clarify the purpose. The instruction '请先调用 agent_catalog' suggests a prerequisite but does not define the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., xlayer_list_subscriptions to view subscriptions, xlayer_subscribe to create one). The only hint is a prerequisite to call agent_catalog, but no context on when unsubscribing is appropriate or what preconditions exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should bear the burden of behavioral disclosure. The description only contains a prerequisite and an informal 'L:READ' tag, which may conflict with the apparent write nature of the tool (submitting a review with 'approved' or 'rejected'). No explanation of side effects or permissions.
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 brief (one short line), but it is underspecified and lacks essential information. It is not concise in a beneficial way; it omits the tool's core purpose and any useful context.
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 has 3 parameters with enums and no output schema, the description is severely incomplete. It fails to explain what the task IDs mean, what the review process entails, or what happens when the tool is invoked. The agent cannot understand the tool's role from this 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?
The input schema has 100% coverage with descriptions for all 3 parameters, so the baseline is 3. The description adds no additional meaning beyond the schema, so it does not improve upon the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It only says '请先调用 agent_catalog' (please call agent_catalog first), which is a prerequisite rather than a purpose. There is no verb+resource identifying the tool's action.
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 prerequisite ('call agent_catalog first'), which is a form of usage guidance. However, it does not specify when to use this tool versus alternatives among the many sibling tools, nor does it explain the context for using 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?
With no annotations, the description carries full burden for behavioral disclosure. The 'L:WRITE' tag implies mutation, but no side effects, permissions, or return behavior are mentioned. The prerequisite is the only additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but lacks substantive information. It front-loads tags and a prerequisite but does not earn its place with clear utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations or output schema, the description is incomplete. It omits return value, confirmation, or any system state changes, leaving the agent without 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 input schema has 100% coverage with Chinese parameter descriptions, so the description does not need to repeat them. However, it adds no cross-references or usage hints for parameters, achieving only the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state that the tool amends a spread order; it only provides a category tag and a prerequisite note. The tool name suggests the purpose, but the description adds no clarifying verb or explanation.
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 a prerequisite ('请先调用 agent_catalog') but offers no guidance on when to use this tool versus alternatives like okx_place_spread_order or okx_cancel_spread_order. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only notes '[L:WRITE]' implying a mutation, but does not disclose what changes occur (e.g., initiates copy trading, modifies settings), side effects, or required permissions. No behavioral details beyond the write indicator.
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 line), making it concise, but it sacrifices clarity with cryptic labels and no structure. It is minimally adequate but not 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?
Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient. It omits the overall action, return value, and usage context, only providing a prerequisite and category. Incomplete for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear Chinese descriptions for parameters (e.g., '跟单数量', '产品类型'). The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a category label '[策略-跟单]' and an action label '[L:WRITE]' but fails to state a specific action verb. It is vague about what the tool actually does, only hinting at copy trading. The name and schema suggest copying a trader, but the description lacks a clear purpose statement.
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 a prerequisite to call 'agent_catalog' first, but does not explain when to use this tool versus alternatives, when not to use it, or how it differs from sibling copy trading tools like 'okx_stop_copy_trader' or 'okx_set_copy_settings'. No usage 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?
With no annotations, the description must carry behavioral disclosure. '[L:READ]' signals read-only, but no further behavioral traits (e.g., mutability, authorization needs, rate limits) are mentioned. The dependency on agent_catalog is noted but incompletely.
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 line with tag and instruction), but its brevity sacrifices clarity. It could be improved by adding a brief purpose statement. Front-loading a READ tag is helpful but insufficient.
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 that this tool likely returns complex options greeks data and has no output schema, the description should provide more context about what the tool returns or how it filters. The current description is too minimal to guide correct 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 100%, so the description does not need to re-iterate parameter details. However, it adds no additional context or examples for the parameters (uly, instId, instType, instFamily). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says '[L:READ] CAT:[账户]' but does not explicitly state that the tool retrieves options greeks. The purpose is implied by the tool name but not clarified. The instruction '请先调用 agent_catalog' (call agent_catalog first) suggests a prerequisite but not the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates a prerequisite ('call agent_catalog first') but provides no guidance on when to use this tool versus alternatives. The sibling list contains many account-related tools, 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 provided, the description carries full burden for behavioral disclosure. It only provides a read hint and category, lacking details on authentication, return format, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one line, but it prioritizes tags and a dependency note over functional explanation. While not verbose, 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?
Despite the tool's simplicity, the description fails to explain the return value or usage of the uid parameter. The dependency on agent_catalog is noted, but overall completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'uid' described as '用户ID'. The description adds no extra meaning beyond the schema, but the baseline is 3 due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description tags the tool as read and promotion category, but does not explicitly state that it retrieves details of an affiliate invitee. The name implies the function, but the description is too vague, effectively tautological.
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 instructs to call agent_catalog first, indicating a prerequisite. However, it does not specify when to use this tool over alternatives like okx_get_affiliate_invitee_list, nor does it provide guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It includes [L:READ] indicating read-only, but does not disclose other behavioral traits such as required permissions, response format, or side effects. The description is insufficient for safe agentic invocation.
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 sacrifices clarity for brevity. It includes a label and a prerequisite, but lacks a clear statement of tool purpose. It is concise but not well-structured for usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description needs to explain the tool's core functionality. It fails to do so, merely hinting at a category and a prerequisite. The tool's purpose and return value remain unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 (100% coverage trivially). With zero parameters, the baseline is 4, but the description adds no parameter semantics. However, since schema coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a category (CAT:[推广]) and a prerequisite ('请先调用 agent_catalog'), but does not state what the tool does with a verb and resource. It is vague and fails to differentiate from sibling tools like okx_get_affiliate_invitee_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to call agent_catalog first, which is a prerequisite, but provides no guidance on when to use this tool versus alternatives. There are no explicit when-to-use or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '[L:READ]' hint indicates read-only, but with no annotations and no further detail, the description fails to disclose critical behavioral traits like return format, data scope, or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but its brevity stems from omission of useful information rather than efficient communication. It is not verbose, but it is under-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?
With no output schema and many sibling tools, the description is too sparse. It does not explain the return value or how it differs from similar contract ratio tools, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (one parameter, well-described). The description adds no additional meaning, so it meets the baseline expectation without compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only categorizes the tool as 'statistics' and instructs to call agent_catalog first. It does not clearly state what 'contract position trader ratio' means or what action the tool performs, leaving its purpose 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?
The description provides a prerequisite (call agent_catalog first) but gives no guidance on when to use this tool versus its many siblings, such as okx_get_long_short_ratio or okx_get_top_trader_long_short_ratio.
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 indicates a read operation via '[L:READ]' but does not disclose what data is returned, side effects, or other behavioral traits. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise but lacks essential information. It fails to communicate the tool's purpose or functionality, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should at least explain what the tool does. Without this, the agent cannot determine when to invoke it or what to expect. The prerequisite is useful but insufficient.
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 the input schema already provides full coverage. The description does not add any parameter information, but baseline 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does. It only includes a category tag and a prerequisite to call 'agent_catalog' first. The purpose is implied by the tool name but not clarified by the description.
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 prerequisite ('please call agent_catalog first') but does not explain when to use this tool versus alternatives like 'okx_get_convert_currencies' or 'okx_convert_trade'. No usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only includes a read hint '[L:READ]' but no further behavioral details such as scope of data, rate limits, or return format. The burden falls entirely on the description, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is economical with words. However, it lacks front-loaded critical information. The structure could be improved by stating the tool's function first.
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 one parameter, no output schema, and no annotations, the description is incomplete. It does not explain what data the tool returns, how to use the parameter effectively, or any related context such as prerequisite tool usage beyond a cryptic instruction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'instType', which is documented as '产品类型' (product type). The tool description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a category label '[L:READ]' and 'CAT:[策略-跟单]' but does not explicitly state what the tool retrieves. 'get_copy_instruments' implies copy trading instruments, but the description is vague and tautological to 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?
The description instructs to call agent_catalog first, which is a prerequisite, but provides no guidance on when to use this tool versus its siblings or alternatives. No differentiation is made among the many OKX tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. Beyond '[L:READ]' (suggesting read-only), there is no disclosure of rate limits, data format, or any behavioral constraints. The description adds minimal value.
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 line), but it lacks substantive information. It is concise but at the expense of clarity. It front-loads the read label but fails to provide minimal functional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotation, the description should clarify what the tool returns (e.g., exchange rates for which pairs). It does not. The tool seems incomplete without calling agent_catalog first, which is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema (100% coverage), so the description does not need to explain parameters. However, the hint to call agent_catalog first suggests that parameters might be derived elsewhere, but the description does not clarify. Baseline is 4, but the vague dependency reduces it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague: it includes '[L:READ]' and 'CAT:[公共]' but does not explicitly state that the tool retrieves exchange rates or for which currencies. It fails to specify the resource or scope, making it hard for an agent to understand its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is '请先调用 agent_catalog' (call agent_catalog first), which implies a prerequisite but does not explain when to use this tool versus alternatives among the many sibling tools. No context on 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 hints at read-only with '[L:READ]'. It does not disclose any behavioral traits such as what data is exposed, side effects, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but poorly structured, using obscure abbreviations and non-standard formatting. It lacks clear sentence structure and is not easily parsable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description fails to explain what the tool returns or how to interpret its output. The instruction to call agent_catalog first is insufficient for a complete 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?
The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter semantics; the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags '[L:READ] CAT:[资金-法币]' implying a read operation on fiat deposits, but it does not specify what exactly is retrieved (e.g., list, details, balance). It fails to distinguish from sibling tools like okx_get_fiat_deposit_orders and okx_get_fiat_deposit_methods.
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 only states a prerequisite ('请先调用 agent_catalog') but provides no guidance on 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?
With no annotations, the description carries the full burden. It only indicates a read operation via '[L:READ]', but does not disclose any behavioral traits such as pagination, limits, or dependencies beyond the vague reference to agent_catalog.
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 line), which is concise but lacks structure. It uses tags and Chinese text, which may not be universally understood. It could be more efficient if it stated the purpose directly.
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 parameters and no output schema, the description should at least explain what the tool returns and how it fits into the workflow. The instruction to call agent_catalog hints at a dependency but is insufficiently explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, so the description does not need to add parameter details. Schema coverage is 100% trivially, earning a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. The label '[L:READ]' and category suggest it is a read operation for fiat deposit orders, but there is no clear verb or resource specification. The instruction '→ 请先调用 agent_catalog' is a prerequisite, not a purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools like okx_get_fiat_deposit or okx_get_fiat_deposit_methods. The only usage hint is to call agent_catalog first, which lacks context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only contains '[L:READ]' which hints at read-only behavior but is not definitive. It does not disclose any other behavioral traits, such as whether it returns historical or current fills, or if it requires authentication.
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 (two fragments) but under-specified. It lacks crucial information about the tool's purpose and usage. Brevity is not beneficial when it omits core meaning.
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 has 3 parameters, no output schema, and no annotations, the description is woefully inadequate. It does not explain what 'fills' are, how to interpret results, or any constraints like pagination. The user is left entirely reliant on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 3 parameters with descriptions, so the description adds no additional parameter semantics. Baseline score of 3 applies since the schema already provides adequate meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses '[L:READ] CAT:[交易]' which is vague and does not clearly state that the tool retrieves filled orders. The name implies it, but the description fails to articulate the function explicitly. It does not distinguish from sibling tools like okx_get_fills_history or okx_get_spread_fills.
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 prerequisite ('请先调用 agent_catalog'), which gives some guidance on order of operations. However, it does not specify when to use this tool versus alternatives, nor does it explain typical use cases or what inputs are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states it's a read operation ('L:READ') but fails to mention what data is returned (e.g., list of loans, dates, amounts) or any side effects. The agent lacks context on what to expect.
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 at the cost of clarity. It is front-loaded with tags, yet the actual content is minimal and uninformative. It could be improved with a brief explanation of what the tool returns.
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 should provide a complete picture. It directs to agent_catalog for more info, but that is external. The description alone is insufficient for an agent to understand the tool's inputs, outputs, or 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?
There are no parameters, and schema coverage is 100%, so the description does not need to add parameter details. The baseline score of 3 is appropriate as the description adds no value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague, only indicating a read operation and a category, without specifying what 'flexible loan history' means. The phrase '→ 请先调用 agent_catalog' suggests the tool's purpose is not self-explanatory and requires external lookup.
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 instructs to call agent_catalog first, which is a usage prerequisite, but it does not provide any guidance on when to use this tool versus similar sibling tools like okx_get_flexible_loan_info or okx_borrow_repay_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The [L:READ] tag suggests a read operation, but there is no explicit disclosure of behavior, return format, or safety implications. The description is too brief to convey 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 extremely concise (one line) but lacks structure. It includes tags and a prerequisite, which is acceptable for a simple tool, but a bit more context would improve usability without adding much length.
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 one parameter, the description should explain what the tool returns. It does not. The prerequisite to call agent_catalog adds some context but is insufficient for complete 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?
The input schema fully describes the only parameter (algoId) with a Chinese description stating it's required. The tool description adds no additional semantic value 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description tags [L:READ] and CAT:[策略-网格] hint at reading grid positions, but the purpose is vague. It does not clearly state that this tool retrieves grid trading positions for a specific algoId, nor does it distinguish from similar tools like okx_get_positions.
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 a prerequisite (call agent_catalog first) but provides no when-to-use guidance, when-not-to-use conditions, or alternatives. This is minimal usability guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only indicates read-only via '[L:READ]' but fails to disclose other behavioral traits like data range, freshness, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it sacrifices informativeness. It lacks a clear statement of the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of the similar sibling okx_get_candles and the lack of an output schema, the description fails to explain how historical candles differ, or how parameters like 'after' and 'before' work for pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameters are well-described in the schema. The description adds no additional semantic value, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides tags ('[L:READ] CAT:[行情]') and a prerequisite instruction, but does not explicitly state that the tool retrieves historical candlestick data. Purpose is implied by the name but not clarified.
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 instructs to call agent_catalog first, which is a usage prerequisite. However, it gives no guidance on when to use this tool over sibling tools like okx_get_candles 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?
The description includes a read hint '[L:READ]' but no other behavioral traits. Without annotations, the description should disclose side effects or return format, which 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but cryptic, making it hard to parse. It is concise but not effectively structured for agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context about what the tool returns and how to interpret the output. With no output schema, the description should compensate but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter 'index' is described in the schema. The description adds no additional semantic value beyond the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state the tool's purpose; it only provides cryptic tags and a prerequisite hint. The name suggests it retrieves index components, but the description lacks 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 on when to use this tool versus alternatives like okx_get_index_tickers. Only a prerequisite instruction to call agent_catalog first is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a '[L:READ]' tag indicating a read-only operation, but no other behavioral details are provided. The lack of annotations means the description carries the full burden, yet it does not disclose outcomes, side effects, or permissions beyond the read hint.
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 but front-loads the READ tag and category. However, the prerequisite instruction is somewhat ambiguous, and the lack of a clear tool purpose makes the conciseness ineffective. It is minimally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description should at least state what the tool returns (e.g., index components). It fails to do so, leaving the agent without a complete understanding of the tool's output and when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description for 'index' (name, example, required). The tool description adds no additional parameter information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a label '[L:READ] CAT:[公共]' and a prerequisite instruction, but does not explicitly state what the tool does. It vaguely implies reading index components market data, but the purpose is unclear without additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to call 'agent_catalog' first, which provides a prerequisite. However, it offers no guidance on when to use this tool versus alternatives like 'okx_get_index_components', nor does it specify any conditions for usage.
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 '[L:READ]' indicating read-only behavior, which adds transparency beyond the absent annotations. However, no other behavioral traits (e.g., data freshness, pagination, or side effects) are disclosed, so it is minimally adequate.
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 with important tags, but the inclusion of Chinese text ('行情' and prerequisite) is cryptic for non-Chinese readers. It is concise but at the expense of 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 and many sibling tools, the description is incomplete. It does not explain the output format, when to use this tool over alternatives, or any other contextual details necessary for proper selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has descriptions for both parameters with 100% coverage. The description adds no additional semantic meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not clearly state what the tool does; it only provides a category label '[行情]' and a prerequisite. The tool name implies it retrieves index tickers, but the description fails to explicitly confirm this, leaving purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its many siblings such as okx_get_ticker or okx_get_index_price. The only instruction is to call agent_catalog first, which is a prerequisite, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only includes '[L:READ]' hinting at read-only, but lacks details on permissions, rate limits, or response behavior. It fails to compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but cryptic, using machine-oriented tags. While concise, it sacrifices clarity and structure, making it less helpful for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling tools and no output schema, the description is severely incomplete. It does not explain return values, usage context, or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'ccy' parameter with full coverage (100%), so the description does not need to add more. It neither adds nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags ('[L:READ] CAT:[统计]') and a prerequisite call but does not explicitly state that the tool retrieves margin lending ratios. Given many sibling tools with similar lending rate functions, this is insufficient for purpose identification.
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 guidance is to call 'agent_catalog' first. There is no indication when to use this tool versus alternatives like okx_get_lending_rate_history or okx_get_lending_rate_summary.
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 cover behavioral traits. It only mentions read operation and category, omitting any details about side effects, required permissions, or data scope.
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 very short but not wasteful. However, its brevity leads to under-specification; it fails to earn its place by providing meaningful content.
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, no annotations, and description does not explain return values or distinguish this tool from numerous similar siblings. It is incomplete for the complexity of the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema coverage is 100%. Description adds no parameter information beyond what schema already shows, but baseline 3 is appropriate.
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 indicates read operation and category 'funds' but does not clearly state what 'non-tradable assets' are or what the tool returns. It vaguely references a prerequisite (agent_catalog) but lacks a specific verb-resource combination.
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?
Provides a prerequisite ('call agent_catalog first') but no guidance on when to use this tool vs alternatives among many sibling tools. No exclusion criteria or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only gives a read hint ('[L:READ]') but fails to mention any behavioral traits such as auth requirements, rate limits, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one line, but it sacrifices informativeness. While not bloated, it does not effectively communicate the tool's purpose or usage, making it merely minimum viable.
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 insufficient for an AI agent to fully understand the tool's behavior and expected output. It lacks details on what the tool returns and how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, so the schema already documents them adequately. The description adds no additional parameter semantics beyond what the schema provides, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state the tool's purpose; it only provides a category tag and a prerequisite. The function is inferred from the name 'okx_get_option_instrument_family_trades', but the description itself is 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?
The description includes a prerequisite note ('请先调用agent_catalog'), but offers no guidance on when to use this tool versus alternatives or when not to use it. No sibling differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only indicates it is a read operation (L:READ). It does not disclose any behavioral traits such as data freshness, rate limits, or side effects, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise but at the expense of clarity. It lacks substantive content to be considered well-structured or front-loaded with useful 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 2 required params, no output schema, no annotations, and a minimal description, the tool is not contextually complete. The description does not explain return values or typical use cases, making it inadequate for effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions (ccy, expTime). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and does not explicitly state that this tool retrieves option open interest by strike. The name suggests it, but the description only says 'L:READ' and a category, which is insufficient to clarify purpose compared to siblings like okx_get_option_oi_expiry.
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 advises to call agent_catalog first, providing a prerequisite but no guidance on when to use this tool versus alternatives (e.g., okx_get_option_oi_expiry). No context for selection among 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?
With no annotations, the description carries full burden for behavioral disclosure. It only hints at read-only via "[L:READ]" but does not explain side effects, permissions, rate limits, or failure modes. The prerequisite hint is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but opaque. It uses specialized notation that assumes prior knowledge. While concise in length, it sacrifices clarity and self-containedness, making it less effective.
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 fails to explain the return value, the concept of open interest, or any additional context needed for correct usage. The agent is left with many unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 parameter fully described). The description adds no additional meaning beyond the schema. Baseline 3 is appropriate since the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It uses coded tags like "[L:READ]" and "CAT:[统计]" and a prerequisite instruction, but the actual purpose (getting option open interest) is only implied by the tool name. This is vague and not helpful for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like okx_get_open_interest. The instruction to call agent_catalog first is a prerequisite, not usage context. The agent receives no help in distinguishing this tool from similar ones.
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 any annotations, the description carries the full burden. It only indicates read-only via "[L:READ]" and a category tag "[统计]", but does not disclose other behavioral traits like data freshness, pagination, rate limits, or what the output represents. The prerequisite hint is useful but 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 very short and front-loaded with the read hint, but it sacrifices clarity for brevity. It is not verbose, but the lack of substantive information means conciseness is not an asset here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, a minimal description might be acceptable, but this one fails to explain what the tool returns and relies on an external call (agent_catalog) without context. The tool is not self-contained or sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description for 'ccy' (currency, required). The tool's description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only contains a read hint and a prerequisite note ("请先调用 agent_catalog") but does not explicitly state what the tool does. The name suggests it retrieves option taker block volume, but the description lacks a clear verb and resource, making it vague compared to sibling tools like okx_get_taker_volume.
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 instructs to call agent_catalog first, which is a prerequisite, but provides no guidance on when to use this tool versus alternatives such as okx_get_taker_volume or okx_get_option_open_interest. There is no when-to-use or when-not-to context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The tag '[L:READ]' hints at read-only behavior, but it is not part of structured annotations. The description does not disclose any other behavioral traits like side effects, rate limits, or authentication needs.
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 but not concise in a helpful manner. It uses cryptic tags and a Chinese instruction, wasting space without conveying useful 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 parameters and no output schema, the description should at least explain the return value or purpose. It fails to do so, offering only a note to call another tool. This leaves the agent with insufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description does not need to add parameter details. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic and does not explicitly state what the tool does. The name 'okx_get_platform_24_volume' suggests retrieving 24-hour volume, but the description only contains tags and a command to call agent_catalog, lacking a clear statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. The only hint is '→ 请先调用 agent_catalog', which is a prerequisite instruction rather than usage 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 exist, and the description provides no behavioral details such as mutability, rate limits, or what data is returned. The [L:READ] tag implies a read operation, but it's not explicit or informative.
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 line), which is concise, but it omits essential purpose and usage information, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and a large set of sibling tools, the description fails to explain what premium history is, how it differs from similar endpoints, or what to expect in the response. The dependency on agent_catalog is noted but not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (instId and period) with 100% coverage, so the baseline is 3. The description adds no additional meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lacks a clear statement of what the tool does. It only provides metadata tags ([L:READ], CAT:[公共]) and an instruction to call agent_catalog first, but no verb or resource indicating that this retrieves premium history 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 similar siblings like okx_get_candles or okx_get_funding_rate_history. The instruction to call agent_catalog first is a dependency hint, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, and description only indicates a read operation via '[L:READ]', lacking details on authentication, side effects, or any behavioral constraints beyond that.
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 the concise format sacrifices clarity; the structure (tag + prerequisite) is minimal yet incomplete for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having many sibling copy trading tools and no output schema, the description fails to explain what the tool returns, how to interpret results, or how it fits into the broader workflow beyond calling agent_catalog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters ('limit' and 'instType') having clear descriptions; the tool's description adds no extra meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:READ]' and 'CAT:[策略-跟单]' without explaining the tool's core function; relies on the name 'get_profit_sharing_details' to imply purpose, but the description itself is 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?
Only provides a prerequisite call '→ 请先调用 agent_catalog' without specifying when to use this tool over siblings like okx_get_profit_sharing_total or other copy trading tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only includes a read hint ([L:READ]) but lacks details on what the tool actually returns, any side effects, or required permissions. This is insufficient for a mutation-aware 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 very short but lacks clarity. It uses a tag-based format and Chinese, which may confuse agents. While it is brief, it is not effectively concise because the content is incomplete and unclear.
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 required parameters and no output schema, the description should explain the return format or data structure. It does not, leaving the agent with insufficient 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 description coverage is 100%; both 'uniqueCode' and 'lastDays' are described adequately in the schema. The description adds no additional meaning beyond what is already in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state the tool's function; it uses cryptic tags (L:READ, CAT) and Chinese text. The purpose is only inferrable from the tool name 'okx_get_public_lead_trader_pnl', which is not ideal for an AI agent.
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 suggests a prerequisite ('请先调用 agent_catalog') but provides no guidance on when to use this tool versus alternatives like 'okx_get_public_lead_traders' or 'okx_get_lead_trader_stats'. No comparative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only hints at read-only nature via '[L:READ]' and mentions a prerequisite, but does not disclose side effects, authentication 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with two phrases, making it concise, but the lack of clarity reduces its effectiveness. It could be more informative without being wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description should at least explain what the tool returns and how to use it. The prerequisite hint is useful, but overall the description is incomplete for an agent to confidently invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'uniqueCode', which is already described as a required unique identifier. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[L:READ]' implying a read operation and includes 'CAT:[策略-跟单]' indicating a category (strategy-copy trading), but does not explicitly state what the tool does. It relies on the tool name to infer that it retrieves a public preference currency for a given trader, which is vague for an agent trying to understand 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes '→ 请先调用 agent_catalog', which provides a prerequisite hint (call agent_catalog first), but lacks guidance on when to use this tool versus alternatives. With many sibling copy trading tools, no explicit context for selection is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The [L:READ] tag hints at a read operation, but the description does not disclose any behavioral traits such as side effects, authorization requirements, or limits. With no annotations, more detail 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short, which is concise, but the use of tags and Chinese characters may reduce clarity for English-speaking agents. It is structured with tags but sacrifices comprehensibility.
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 and many siblings, the description fails to provide enough context. It does not explain what data is returned, how the tool fits into the RFQ workflow, or what 'quotes' means. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'rfqId', whose description already states 'RFQ ID。必填'. The tool description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is vague; uses tags [L:READ] and category but does not explicitly state what the tool does. The user must infer from sibling tools and parameter name 'rfqId' that it retrieves quotes for an RFQ. Lacks a clear verb+resource statement.
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?
Provides a prerequisite ('请先调用 agent_catalog') but no guidance on when to use this tool vs alternatives like okx_get_rfqs or okx_execute_quote. No comparison or 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?
With no annotations provided, the description carries the full burden. It includes [L:READ] indicating a read-only operation, but omits other behavioral traits such as authentication requirements, rate limits, or what the response contains. The disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short line), but it sacrifices informativeness. It could include more useful details in the same space, such as the time range or return format.
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 (many savings-related siblings, no output schema), the description is insufficient. It does not specify that the tool retrieves historical savings transactions, nor does it mention pagination, date range, or response structure. This leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage: the single optional parameter 'ccy' is described as '币种，如 USDT' (currency, e.g., USDT). The description adds no additional parameter semantics beyond what is already in 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only contains cryptic tags ([L:READ], CAT:[金融]) and a prerequisite instruction, but does not explicitly state that the tool retrieves savings history. The purpose is vaguely implied by the tool name but not clarified.
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 instructs to call agent_catalog first, but provides no guidance on when to use this tool versus related siblings like okx_get_savings_balance or okx_purchase_savings. No conditions, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only contains a non-standard '[L:READ]' hint, which vaguely suggests read-only behavior but lacks clarity. No disclosure of side effects, idempotency, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines), which is concise but at the expense of content. It includes a prerequisite instruction that may be better placed elsewhere. It is not front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is severely lacking. It does not explain what the output looks like, how pagination works, or any context about savings lending rates. The agent cannot confidently use this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 the single parameter 'ccy', which is well documented. The tool description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[统计]' is vague and does not explicitly state that the tool retrieves the lending rate for savings. It implies a read operation and statistics category but lacks a clear verb and 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?
The description instructs to 'call agent_catalog first', but does not provide any guidance on when to use this tool versus its many siblings (e.g., okx_get_savings_balance, okx_get_lending_rate_history). No when-to-use or when-not-to-use advice.
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 only marks the tool as read '[L:READ]' but fails to describe expected behavior, idempotency, rate limits, or the structure of returned data. Schema implies it's a fetch operation, but behavioral details 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 very short, which is concise, but the content is cryptic (brackets, Chinese arrow). It is not well-structured for an English-speaking agent; the format is confusing and lacks 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?
No output schema, so description should clarify return format and usage context. It mentions a prerequisite (agent_catalog) but does not explain what agent_catalog provides or how to interpret the candles data. The description is incomplete 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.
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. Description does not add any parameter-specific information beyond what the schema already provides. No additional meaning is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic, using '[L:READ] CAT:[策略-价差]' instead of a clear statement like 'Get spread candlesticks'. The purpose is inferred from the tool name and schema, not stated. The description adds little value beyond labeling.
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 siblings like okx_get_spread_ticker or okx_get_spread_books. The only note is a prerequisite to call agent_catalog, but no comparison or 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 it is a read operation via '[L:READ]' but provides no details about authentication, rate limits, or what happens when called. With no annotations, the description fails to disclose behavioral traits beyond the basic read hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one line) but is cryptic and uses obscure prefixes. It could be shorter if clearer, but as written it is not effectively informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values, which is critical since there is no output schema. It also does not explain the data structure or how fills relate to spreads, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with descriptions for limit and sprdId. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[策略-价差] | → 请先调用 agent_catalog'. It does not explicitly state that the tool retrieves fills for spread orders, relying on the name to imply the purpose. The instruction to call agent_catalog first adds confusion without clarifying the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like okx_get_spread_orders or okx_get_spread_trades_fills. The only hint is to call agent_catalog first, which is a prerequisite, 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.
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 includes a read hint '[L:READ]' (embedded, not standard annotation) but omits details like authentication needs, rate limits, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not wasteful. However, it trades brevity for clarity, providing minimal useful information. It is adequately sized but under-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 many sibling spread order tools and no output schema, the description fails to explain return values, ordering, or whether it covers pending/historical orders. It lacks necessary context for a tool with limited structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter sprdId with a description ('价差合约ID'). The tool description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only tags the tool as a read operation for '策略-价差' (spread strategy) but does not specify what it retrieves (e.g., list of orders, details). It does not distinguish from sibling tools like okx_get_spread_orders_pending or okx_get_spread_orders_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?
The description mentions a prerequisite ('请先调用 agent_catalog') but gives no guidance on when to use this tool vs. 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 are provided, so the description should disclose behavioral traits. It only states '[L:READ]' (presumably read-only) but does not mention authentication, rate limits, side effects, or return behavior. The description fails to 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?
Very short (one line), but the structure is minimal and includes a prerequisite instruction. While concise, it lacks front-loading of purpose and is more like an internal note than a clear explanation.
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 one parameter and no output schema, the description should provide more context such as what the tool returns, how to obtain the spread ID, or typical use cases. The prerequisite to call agent_catalog is mentioned but not elaborated, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (one parameter, 'sprdId', described as '价差合约ID'). The tool description adds no further meaning beyond the schema. Score is baseline 3 as schema already covers the parameter's purpose.
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 does not clearly state what the tool does. It includes a category tag '[L:READ]' and a reference to 'CAT:[策略-价差]' but no explicit verb-noun pair like 'Get spread fill trades'. The purpose is ambiguous, especially given similar sibling tools like 'okx_get_spread_fills' and 'okx_get_spread_trades'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The only instruction is '请先调用 agent_catalog' (call agent_catalog first), which is a prerequisite but does not help an AI agent decide when to select this tool over other spread-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?
No annotations are provided. The description includes a [L:READ] tag hinting at read-only behavior, but no further details about safety, side effects, or rate limits. Behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It omits essential information about the tool's purpose and behavior, making it insufficient for an agent to understand when and how to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description should still explain the tool's function and return value. It fails to do so, leaving the agent with insufficient context to infer the tool's behavior.
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, so there is nothing to describe. The description does not add parameter semantics, but that is acceptable given zero parameters. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only contains a tag indicating read-only and a category, plus an instruction to call agent_catalog. It does not explicitly state that this tool retrieves stable rewards history, relying on the name. Purpose is vague and not clearly 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 suggests a prerequisite (calling agent_catalog) but provides no guidance on when to use this tool vs siblings, or what context it is appropriate for. Minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only provides a '[L:READ]' tag (likely read-only) and a category, but no details on authentication, rate limits, or consequences of not calling agent_catalog first.
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, but it uses opaque tags that may confuse an AI agent. It is not particularly helpful despite being 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?
With no output schema and 4 parameters (1 required), the description provides no information about return values, pagination, or behavior. The sole directive to call agent_catalog first is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with Chinese descriptions for all 4 parameters. The tool description adds no information beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a cryptic tag '[L:READ]' and tells to call agent_catalog first, but does not explicitly state the tool's action. The purpose is mostly inferred from the name 'get_subaccount_bills', making the description a tautology.
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 usage guidance is '先调用 agent_catalog' (call agent_catalog first), which is a prerequisite. There is no mention of when to use this tool versus alternative sibling tools like okx_get_subaccount_balance or okx_get_subaccount_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The [L:READ] tag hints at read-only behavior, but no other behavioral traits (e.g., required permissions, rate limits, or side effects) are disclosed. With no annotations, the description should provide more depth.
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 the structure is functional. It could be better organized to front-load the core purpose instead of relying on tags.
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 tool's purpose (retrieving trading balance), the description should explain what data is returned or why agent_catalog is needed. It is incomplete for effective 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 100% and the parameter 'subAcct' is described in the schema. The description adds no additional meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a vague 'L:READ' and category tag, but does not explicitly state that the tool retrieves the trading balance for a subaccount. The name implies this, but the description fails to clarify.
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?
Only a prerequisite note ('请先调用 agent_catalog') is provided, with no guidance on when to use this tool vs. sibling tools like okx_get_subaccount_balance, or any context about 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 provided, the description carries the full burden of disclosing behavioral traits. It only indicates read-only via '[L:READ]', but does not detail what data is returned, if side effects exist, or any other behavioral aspects. This is minimally informative.
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 includes a tag, category, and instruction. While concise, it sacrifices clarity for brevity. The structure is organized but the content is insufficient.
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 (no parameters, no output schema), the description should still explain what the tool returns or what 'system status' means. It fails to provide a complete understanding, leaving the agent uncertain about the output's nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is trivially 100%. The description adds no extra parameter meaning, which is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags ('[L:READ]', 'CAT:[行情]') and an instruction to call agent_catalog, but does not explicitly state that the tool retrieves the OKX system status. The purpose is vaguely implied by the tool name, but the description adds no concrete 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?
The description includes a prerequisite ('→ 请先调用 agent_catalog'), providing some usage context. However, it lacks guidance on when to use this tool versus alternative tools like okx_get_system_time or okx_get_account_rate_limit, and does not describe appropriate 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?
The '[L:READ]' tag implies read-only behavior, but no further behavioral details are provided (e.g., no mention of permissions, rate limits, or side effects). With no annotations, the description carries the full burden 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 extremely concise (one line), but its cryptic format ('[L:READ] CAT:[统计]') lacks clear structure and could be confusing.
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 4 parameters and no output schema, yet the description does not explain what data is returned or how the prerequisite 'agent_catalog' relates to usage. Incomplete for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already documented. The description adds no additional meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[统计] | → 请先调用 agent_catalog' does not explicitly state the action of retrieving taker volume. It indicates a read operation and a category but relies on the tool name 'okx_get_taker_volume' to infer purpose, which is 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?
The description provides a prerequisite ('请先调用 agent_catalog') but offers no guidance on when to use this tool versus alternatives like okx_get_taker_volume_contract or other statistics tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only indicates a read operation via '[L:READ]', but omits whether it is idempotent, requires permissions, rate limits, or what happens on invalid transfer IDs. The note to call agent_catalog hints at dependency but 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 very short but not well-structured for clarity. The use of brackets and a pipe may be a tag system, but it lacks a front-loaded action statement. It is concise but not optimally ordered for an agent to quickly grasp the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description should provide more context about what the tool returns, how to interpret the state, and why agent_catalog must be called first. The current description is incomplete for safe and 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 100% for the single parameter 'transferId', which already states it is required and obtained from okx_transfer. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a cryptic tag '[L:READ] CAT:[资金]' which suggests a read operation on funds but does not explicitly state 'check transfer state' or 'get transfer status'. The tool name is somewhat self-explanatory, but the description adds no clear verb-resource statement, relying on inference.
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 only says '→ 请先调用 agent_catalog' (call agent_catalog first), which is a prerequisite but no guidance on when to use this tool versus alternatives. It does not mention when not to use it or compare with sibling tools like okx_transfer.
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 includes '[L:READ]' hinting at read-only behavior, but lacks disclosure about authentication, rate limits, side effects, or data presentation. Minimal transparency beyond the read hint.
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 brief but not concise in a helpful way. It uses cryptic tags and a prerequisite note without structuring information clearly for an AI agent. It could be more readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and vague description, the tool is incomplete. It does not explain what the response contains, how to interpret results, or how it differs from related tools like okx_get_total_unrealized_profit_sharing.
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 schema coverage is 100%. The description adds no meaning beyond the schema, but baseline for 0-parameter tools is 4. No param info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'L:READ' and 'CAT:[策略-跟单]' suggest it's a read operation in the copy trading category, but it does not explicitly state that the tool retrieves unrealized profit sharing details. The purpose is implied by the name but not clearly articulated.
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 instruction '请先调用 agent_catalog' indicates a prerequisite (call agent_catalog first), but it does not provide guidance on when to use this tool over alternatives (e.g., okx_get_total_unrealized_profit_sharing) 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 hints at a write operation with '[L:WRITE]'. It lacks details on authorization needs, rate limits, or the fact that this tool modifies account state by creating orders. The behavioral burden falls entirely on the description, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), which is concise but at the expense of clarity. The cryptic tags are not self-explanatory, and the important instruction to call agent_catalog is buried. The structure does not effectively communicate the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool like placing an order, the description lacks information about return values, failure modes, side effects, or post-call actions. The absence of an output schema amplifies this gap. Agents are left guessing about what happens after invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear parameter descriptions and enums. The tool description adds zero parameter-level information, but the schema already does a good job. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like '[L:WRITE]' and 'CAT:[交易]' but does not explicitly state that the tool places an order. It relies heavily on the tool name 'okx_place_order' for clarity, which is insufficient for agents unfamiliar with the naming convention.
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 a prerequisite instruction to call 'agent_catalog' first, but provides no guidance on when to use this tool versus sibling tools like 'okx_place_algo_order' or 'okx_event_place_order'. Agents cannot differentiate based on this description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes '[L:READ]' which indicates a read-only operation, but with no annotations provided, the description carries the full burden. It does not disclose any other behavioral traits such as authentication requirements, rate limits, or side effects. Additional context from the '[L:READ]' tag is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (a single line), which is good for conciseness, but it sacrifices clarity and usefulness. It could be improved by adding a brief statement of the tool's core function while remaining brief.
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 (one parameter, no output schema), the description fails to explain what the tool returns or the context in which it should be used beyond the prerequisite call. It is incomplete for an agent to effectively decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter 'eventId' with a description '事件ID，必填'. The tool description adds no additional meaning or context for the parameter beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses '[L:READ]' implying a read operation and 'CAT:[预测]' indicating the predictions category, but it does not explicitly state that the tool retrieves a specific prediction event by ID. The mention of '请先调用 agent_catalog' is a prerequisite, not a purpose statement. This is vague and does not clearly distinguish the tool from siblings like okx_predictions_list_events or okx_predictions_search_events.
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 only gives a prerequisite instruction ('请先调用 agent_catalog') which is a usage hint but does not explain when to use this tool over alternatives such as okx_predictions_list_events or okx_predictions_search_events. No contextual guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; '[L:READ]' is an informal hint but not a standard annotation. Description does not disclose side effects, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short but cryptic; the prerequisite note is front-loaded but unclear. Could be more concise and 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?
No output schema and description does not explain what the tool returns or how to interpret results. Incomplete for a get-order operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for orderId with description '订单ID（必填）', so schema adequately explains the parameter. Description adds no extra meaning.
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 is vague; 'L:READ' and 'CAT:[预测]' hint at read-only predictions but do not clearly state the tool retrieves an order. The name implies it, but description lacks explicit verb and 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?
Only mentions prerequisite to call agent_catalog first, but provides no guidance on when to use this tool vs alternative prediction tools (e.g., okx_predictions_order_list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It includes '[L:READ]' hinting at read-only behavior, but does not disclose any other behavioral traits (e.g., what happens to data, authorization needs). This is minimal and 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 very short and front-loaded with the prerequisite. While concise, it sacrifices clarity and completeness, making it only adequate.
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 search tool with no output schema and one parameter, the description should at least state the purpose and return value. It does neither, only providing a category and dependency. This is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the single parameter 'keyword', which is clearly described as '搜索关键词，必填'. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description fails to explicitly state what the tool does. It only provides a category label ('CAT:[预测]') and a prerequisite instruction, but does not say 'searches for prediction events' or similar. The tool name suggests searching, but the description is 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?
The description gives a prerequisite ('call agent_catalog first'), but does not provide context on when to use this tool versus siblings like okx_predictions_list_events. No differentiation or exclusion criteria are 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 carries full burden. It only discloses that it is a write operation via '[L:WRITE]', but does not describe side effects, required permissions, or whether the split is 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, but it is not well-structured. It uses brackets and a symbol inconsistently. Still, it is concise and 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?
Given the tool is a write operation with no output schema, the description should explain what splitting does and what happens after. It only mentions a prerequisite, leaving the agent without a clear understanding of the tool's effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 'amount' has schema description '拆分数量（必填）' meaning 'split quantity (required)'. The tool description does not add further meaning, but schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:WRITE] CAT:[预测] | → 请先调用 agent_catalog' is vague. It indicates a write operation and a category but does not clearly state that this tool splits predictions. The verb 'split' is only in the name, not 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 advises to call agent_catalog first, which is a prerequisite. However, it offers no guidance on when to use this tool vs alternatives like okx_predictions_merge or other okx_predictions 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 exist to disclose safety or side effects. The description only marks a write operation ('L:WRITE') via a cryptic prefix, but does not explain what the switch does, whether it is destructive, authentication needs, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which makes it concise but at the cost of clarity. The cryptic prefix uses internal jargon that may not be useful to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and many sibling tools, the description fails to provide sufficient context. It does not explain return values, prerequisites beyond agent_catalog, or how switching differs from other account operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'acctLv' has a clear description (target account level, required). The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague; it uses a cryptic prefix '[L:WRITE] CAT:[账户]' and a Chinese hint to call agent_catalog first, but does not explicitly state that the tool switches an account preset. It does not distinguish from sibling tools like okx_set_account_mode or okx_get_account_config.
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?
Only a prerequisite to call agent_catalog first is given. No explicit when, when-not, or alternatives among the many account-related 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, and the description does not disclose behavioral traits such as whether the operation is destructive, what permissions are needed, or side effects. The '[L:READ]' hint is ambiguous for a reset action.
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 could be improved by using clearer language instead of cryptic symbols. It prioritizes compactness over 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?
For a tool named 'reset_rfq_mmp', the description is too sparse. It does not explain the tool's behavior, return values, or relationship to other tools. Given the lack of output schema and annotations, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the schema leaves no room for additional meaning. However, the description does not add any context about what the tool resets or how it works, which would be helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what 'reset_rfq_mmp' does. It only includes a category label and a hint to call agent_catalog first. The purpose is vague and requires inference from the tool name and 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the user to call agent_catalog first, but does not provide any context on when to use this tool versus alternatives like okx_reset_mmp or okx_set_mmp_config. No exclusions or comparison are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as irreversibility, fees, success/failure outcomes, or required permissions. For a financial action 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 very short (two elements), but it is not front-loaded with purpose. The directive to call agent_catalog takes precedence, which is not the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a withdrawal action with no output schema and no annotations, the description should explain behavior, risks, and return values. It only provides a category and a prerequisite, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with Chinese descriptions for all three parameters (ccy, amt, to). The description adds no additional meaning beyond the schema, but the schema itself is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses '[L:FUND_TRANSFER]' to suggest a fund transfer category, but does not explicitly state that the tool is for withdrawing funds via Lightning Network. The main content is a directive to call agent_catalog first, leaving the tool's purpose 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?
The description mentions a prerequisite (call agent_catalog) but provides no guidance on when to use this tool versus alternatives like the standard okx_withdrawal tool. There are no exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only hints at read-only behavior with '[L:READ]' but fails to disclose important behavioral traits such as the need for prior authentication, the fact that it establishes a long-lived WebSocket connection, or what happens upon subscription (e.g., data streaming).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it lacks essential information. It front-loads a prerequisite instruction, but the overall structure is too sparse to be effective. While brevity is valued, it sacrifices clarity and 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 (WebSocket subscription), the absence of annotations and output schema, and the cryptic description, the context is severely incomplete. The description does not explain the return values, side effects, or the lifecycle of the subscription, making it difficult 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 description coverage is 100%, so the baseline is 3. The tool description adds no additional meaning to the parameters beyond what the schema already provides. It does not explain the channel values or the instId field, which are fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague and does not clearly state the purpose of the tool. It only contains cryptic tags like '[L:READ]' and 'CAT:[行情-WS]' without explaining that the tool is for subscribing to private WebSocket channels. The instruction '请先调用 agent_catalog' is a prerequisite, not a purpose statement.
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?
Minimal usage guidance is provided. The description instructs to call 'agent_catalog' first, but it does not specify when to use this tool over alternatives or provide any context about the appropriate scenarios for private subscription. No exclusions or comparisons with siblings 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 exist, so the description must disclose behavior. The [L:READ] tag hints at read-only but is not explicit. No mention of side effects, authorization, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but cryptic; it sacrifices clarity for brevity. It is not well-structured for agent interpretation.
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 fails to explain the return format or what markets are listed. For a list tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (pageSize) is present, and its schema description covers 100% of the meaning. The tool description adds no additional semantics, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags like [L:READ] and CAT:[预测] without explaining what the tool does. The name 'outcomes_list_markets' suggests listing markets, but the purpose is vague and not clearly stated in plain language.
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 instruction '请先调用 agent_catalog' provides a prerequisite but no guidance on when to use this tool versus alternatives like outcomes_list_events. No explicit when-not-to-use 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?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only or destructive. The prefix '[L:READ]' might hint at read-only, but it's unclear. The description does not add behavioral context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but at the expense of clarity. It is not front-loaded with a clear purpose and uses cryptic notation that may confuse an AI agent.
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 an enum parameter and a prerequisite, the description is insufficient. It does not explain what dispatching a task entails, the outcome, or how to interpret the taskId values. No output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both parameters. The tool description does not add additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic with '[L:READ] CAT:[系统]' and a hint to call agent_catalog first. It does not clearly state what the tool does. The verb 'dispatch' implies sending a task, but the purpose is vague.
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 tells the agent to call agent_catalog first, providing a prerequisite. However, it does not specify when to use this tool versus alternatives, nor does it explain the context for its 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 are provided, and the description only includes a bare '[L:READ]' hint. There is no disclosure of potential side effects, authentication needs, or other behavioral traits beyond the read-only implication.
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 brief and uses structured tags efficiently. However, it could be more informative without adding significant length, such as clarifying the return 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 no parameters, annotations, or output schema, the description fails to provide sufficient context about what the tool returns or its role. The single instruction about agent_catalog is insufficient for a complete 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?
The tool has zero parameters, so the description needs to add minimal value beyond the schema. The instruction to call agent_catalog first provides operational context, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates a read-only system tool and instructs to call agent_catalog first, but it does not explicitly state what status is being checked or what the tool outputs. The purpose is implied but ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only provides a prerequisite (call agent_catalog first) but lacks guidance on when to use this tool versus alternatives. No context on selection criteria is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The [L:WRITE] marker implies it is a mutating operation, but there is no explanation of side effects, permission requirements, rate limits, or expected outcomes. This is insufficient for an AI agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concise; it is cryptic and lacks clarity. The use of Chinese abbreviations and the instruction to call agent_catalog first may confuse an agent. It could be more informative 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 there are 3 required parameters, no output schema, and no annotations, the description is very incomplete. It fails to explain what the tool returns, error conditions, or how to interpret the result. The requirement to call agent_catalog first is mentioned but not explained. The tool's context is poorly defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage). The tool description does not add any additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate since the schema alone is minimal but complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only indicates it's a write operation for account category, but does not explicitly state that the tool is for borrowing or repaying funds. The name 'borrow_repay' hints at the action, but the description is vague and relies on Chinese terms and a prerequisite call to agent_catalog.
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 instructs to call agent_catalog first, which serves as a usage prerequisite. However, it does not specify when to use this tool versus other account-related tools (e.g., okx_get_balance, okx_get_loan_info) or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only indicates a write operation ('[L:WRITE]'), but does not disclose behavioral traits such as authentication requirements, side effects, rate limits, or what exactly is created. The description lacks sufficient detail.
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 but cryptic, using non-standard abbreviations and a reference to another tool. While concise, it sacrifices clarity and does not front-load useful information. The structure is not helpful for an AI agent.
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 creation tool with many sibling subaccount tools, the description is incomplete. It does not explain return values, prerequisites beyond calling agent_catalog, or what happens after creation. Without an output schema, the tool's behavior is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with Chinese descriptions for both parameters: 'subAcct' (required, subaccount name) and 'label' (remark). The description adds no additional meaning beyond the schema. With high coverage, baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic, using Chinese tags like '[L:WRITE]' and 'CAT:[账户-子账户]', and directs to call agent_catalog first. It does not clearly state that it creates a subaccount, relying on the tool name for inference. The purpose is barely conveyed.
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 a prerequisite ('请先调用 agent_catalog'), which provides some guidance on when to use this tool. However, it does not differentiate from sibling subaccount-related tools (e.g., okx_list_subaccounts, okx_get_subaccount_balance) 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.
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 indicates 'WRITE' (mutation), but lacks details on destructive hints, idempotency, authentication, or rate limits. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line) but uses cryptic tags and Chinese, which undermines clarity. It is not effectively structured for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancel-order tool with 2 parameters and no output schema, the description lacks important context like success/error behavior, prerequisites beyond calling agent_catalog, and return value. It is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with Chinese descriptions for both parameters. The description does not add any additional semantics beyond the schema, so baseline score of 3 is appropriate.
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 name clearly indicates canceling an event order, and the description's 'WRITE' and category 'Predictions' add context, but the description lacks an explicit statement of the tool's function. It is not a tautology but still 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?
The description instructs to call agent_catalog first, implying a prerequisite, but does not specify when to use this tool over alternatives like okx_event_amend_order or okx_cancel_order. No alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only includes a read hint via '[L:READ]' (not part of description) and the prerequisite, missing details on return format, rate limits, 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?
The description is extremely short (one line), achieving conciseness, but the content is minimal. The prerequisite instruction is useful, yet the description could be clearer about the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no output schema or annotations, the description is insufficient. It does not explain what data is returned, how to interpret results, or the significance of 'full' in the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 is 3. The description adds no additional meaning to parameters beyond the schema, which already documents 'instId' and 'depth'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a category tag 'CAT:[行情]' and a prerequisite, but does not explicitly state what the tool does. The tool name 'get_books_full' suggests retrieving full order book data, but the description lacks a clear verb-resource statement.
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 instructs to call 'agent_catalog' first, which is a prerequisite, but offers no guidance on when to use this tool versus alternatives like 'okx_get_orderbook' or other market data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only includes '[L:READ]' which might imply read-only, but it is not explicit. There is no mention of side effects, authentication 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line with notation and Chinese), which is concise but lacks a clear structure. It could be more informative 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 zero parameters, no output schema, and no annotations, the description should provide context about return values and role. It only notes a prerequisite, leaving the agent unsure about what the tool actually returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already defines them. The description does not need to add parameter details, and it does not contradict or mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic with '[L:READ] CAT:[策略-跟单]' and does not clearly state that the tool retrieves copy trading settings. It hints at being a read operation related to a strategy category, but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guideline is '→ 请先调用 agent_catalog', indicating a prerequisite. There is no guidance on when to use this tool versus alternatives like okx_set_copy_settings or okx_get_copy_traders.
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 indicates a read operation ('READ') but fails to describe what the tool actually does, whether it has side effects, or any limitations. The instruction to call agent_catalog adds confusion rather than clarity.
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, but lacks meaningful content. Conciseness is only valuable when information is effectively conveyed; here, it sacrifices clarity 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 simplicity of the tool (one optional parameter, no output schema), the description still fails to explain the purpose or expected return values. The instruction to call agent_catalog is cryptic and does not compensate for missing context.
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 100% description coverage, with the 'ccy' parameter already documented. The description adds no additional value beyond what the schema already provides, so a baseline score of 5 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a read hint and category tag ('[L:READ] CAT:[资金]'), without explicitly stating the tool's purpose. The name 'okx_get_currencies' suggests retrieving currencies, but the description does not confirm this or specify what information 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains an instruction to call agent_catalog first, but does not explain when to use this tool versus alternatives like okx_get_ticker or okx_get_instruments. No guidance on context or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only hints at a read operation via '[L:READ]' but does not explain side effects, authentication needs, rate limits, or the consequence of not calling agent_catalog. With no annotations provided, the description carries the full burden and 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) and thus concise, but it uses cryptic tags that are not self-explanatory. It lacks clear structure for human or AI readability, earning a middling 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?
With no output schema and no annotations, the description should explain what the tool returns and how it fits into the easy-convert workflow. It only instructs to call agent_catalog, leaving the agent without sufficient context about the tool's purpose and output.
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), and schema coverage is 100% trivially. The baseline score is 4 as per guidelines. The description does not add parameter-related meaning but does not detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags ('[L:READ]', 'CAT:[交易]') and a vague instruction to call agent_catalog, but does not explicitly state that this tool retrieves a list of currencies available for easy conversion. It fails to differentiate from similar sibling tools like okx_get_convert_currencies.
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 guidance is to call agent_catalog first, which is a prerequisite but not a complete usage guideline. No information is provided about when to use this tool versus alternatives (e.g., okx_get_easy_convert_history, okx_get_convert_currencies) or when to avoid 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. The description hints at a read operation via '[L:READ]' but omits behavioral details such as authentication needs, rate limits, or whether it has side effects. Transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but uses unstructured labels and Chinese that may hinder agent understanding. It could be better structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description lacks context about the tool's return value, behavior, or how it fits into subaccount management. It is incomplete for an agent to reliably use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so 100% coverage is trivial. The description does not need to add parameter meaning, as there are none. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a cryptic label '[L:READ]' and Chinese category, but does not explicitly state that this tool retrieves a list of entrust subaccounts. The purpose is vague and relies on the tool's name for 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?
The description provides a prerequisite ('please call agent_catalog first') but gives no guidance on when to use this tool versus sibling tools like 'okx_get_subaccount_list' or others. Usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates read-only via '[L:READ]', but fails to disclose whether authentication is needed, side effects, rate limits, or data scope. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but under-specified. It is concise but not well-structured; the instruction to call agent_catalog is unclear. Could be improved without adding length.
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 parameters and no output schema, the description should at least state what the tool returns or its purpose clearly. It does not, leaving the agent to guess. Not complete enough for a zero-param 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, so the description does not need to add parameter information. Baseline is 4 for 0-param tools, and the description does not contradict or add confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague and does not explicitly state that it retrieves ETH staking balance. It uses coded tags like '[L:READ]' and 'CAT:[金融]' but no clear verb+resource statement. The name provides some clue but the description itself is insufficient.
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 an instruction to call agent_catalog first, implying a prerequisite, but does not provide any guidance on when to use this tool vs alternatives like okx_get_eth_staking_history or other staking tools. No explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only indicates a read operation via '[L:READ]' and a category, but lacks details on what the tool does internally, what data it accesses, or any side effects. The minimal disclosure is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, which could be considered concise, but it sacrifices clarity. The use of brackets and arrows (e.g., '[L:READ]', '→') is somewhat structured, but the overall message is ambiguous. It could be both more concise and clearer.
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 that there is no output schema and the tool appears to list exchanges, the description should explain what the list contains (e.g., exchange names, IDs) or provide a sample. It only mentions a prerequisite, leaving the agent without enough 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is empty. The description adds no meaning beyond what the schema provides, but per the guidelines, 0 parameters gets a baseline of 4. No further semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[资金] | → 请先调用 agent_catalog'. It does not explicitly state that this tool returns a list of exchanges; the name suggests it, but the description fails to confirm. The category and prerequisite are unclear, making the purpose 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?
The description only provides a prerequisite ('请先调用 agent_catalog'), which implies a certain order of operations. However, it offers no guidance on when to use this tool versus the many sibling tools, nor does it mention any alternatives 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 provided, the description must disclose behavioral traits. The '[L:READ]' tag suggests the tool is read-only, and the instruction '请先调用 agent_catalog' establishes a prerequisite. However, it does not describe authentication needs, rate limits, or what happens on failure. The information is minimal but not contradictory.
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 brief, consisting of only two short phrases. However, it prioritizes metadata over clarity, with no explanatory sentence about the tool's core purpose. The prerequisite note is useful but poorly positioned, and the overall structure is not front-loaded for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of an output schema, the description should at least confirm what the tool returns. It fails to provide any context about the output or how the parameters affect results. The prerequisite mention is helpful but not sufficient for an agent to understand the tool's full scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (uly, instId, instType) with clear descriptions, achieving 100% schema coverage. The tool description adds no additional meaning or context for the parameters, so it meets the baseline without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state the tool's function. It only contains metadata tags like '[L:READ]' and 'CAT:[账户]' plus a directive to call 'agent_catalog' first. The name 'okx_get_fee_rates' implies retrieving fee rates, but the description fails to confirm this, leaving the purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Among many sibling tools like okx_get_ticker or okx_get_trade_fee, there is no differentiation or context for selecting this tool. The directive to call agent_catalog first is a prerequisite but does not clarify usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It provides a read hint ([L:READ]) but no details on side effects, auth requirements, rate limits, or data scope. The agent cannot assess safety or 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 very short but cryptic, using internal markers like '[L:READ] CAT:[金融]'. It is not front-loaded with a clear purpose. While concise, it sacrifices clarity 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 no output schema and 0 params, the description should explain what the tool retrieves. It only says to call agent_catalog, which is incomplete. The agent has no understanding of the tool's output or relevance.
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 no parameters, so the description does not need to explain them. Baseline for 0 params is 4. However, the description could add value by hinting at what the tool returns, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic: '[L:READ] CAT:[金融] | → 请先调用 agent_catalog'. It indicates a read operation and finance category but does not clearly state what 'flexible loan info' is or what the tool does. The arrow suggests a prerequisite but not the core 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 only guidance is to call agent_catalog first. No explicit when-to-use, when-not-to-use, or comparison with sibling tools like okx_get_flexible_loan_collateral or okx_get_flexible_loan_history. The agent is left guessing the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only includes '[L:READ]' to indicate read-only, but fails to disclose any behavioral traits such as pagination, rate limits, or what happens when no orders exist. For a history 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this conciseness comes at the cost of clarity. It uses cryptic abbreviations (e.g., 'L:READ', 'CAT:') that may not be universally understood. A longer, human-readable explanation would be more helpful. The structure is not front-loaded with 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?
Given that there is no output schema, the description should explain what the tool returns, but it does not. It also omits details like default time range or maximum results. The schema is simple, but the missing output information makes the tool incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions in Chinese. The tool description adds no additional meaning or formatting details beyond what the schema provides. Baseline score of 3 applies since the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'okx_get_grid_orders_history' clearly indicates the tool retrieves history of grid orders. The description adds '[L:READ]' hinting it's a read operation and 'CAT:[策略-网格]' suggesting category. However, it lacks an explicit English statement of purpose, relying on the name and cryptic tags.
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 a prerequisite '请先调用 agent_catalog' (please call agent_catalog first) but provides no guidance on when to use this tool versus sibling grid tools like okx_get_grid_orders_pending or okx_get_grid_sub_orders. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It includes a custom read-only tag '[L:READ]', which is helpful for safety, but it does not disclose other traits such as authentication requirements, rate limits, or any side effects (e.g., 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines) but under-specifies the tool's purpose and behavior. While it is concise, it sacrifices completeness for brevity. It could benefit from a clear sentence about what the tool does.
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 3 parameters, no output schema, and no annotations, the description does not adequately explain the tool's return values, parameter behavior, or typical usage. The prerequisite hint is useful but insufficient 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 100%, so the input schema documents all three parameters. The description adds no additional parameter context beyond what is already in the schema. The baseline of 3 is appropriate.
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 hints at a read operation related to copy trading via the tag '[L:READ] CAT:[策略-跟单]', but does not explicitly state that the tool retrieves lead trader history. The name 'okx_get_lead_trader_history' is clear, but the description lacks a direct verb+resource statement.
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 only provides a prerequisite ('请先调用 agent_catalog') but offers no guidance on when to use this tool versus alternatives like okx_get_lead_trader_positions or okx_get_lead_trader_stats. There is no when/why context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present. Description offers only the 'L:READ' hint to indicate a read operation, but lacks disclosure of other behavioral traits like authentication needs, side effects, or response structure.
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 very short and front-loaded with the read label and category, but it lacks substantive content about the tool's function, making it minimally useful despite being concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description fails to provide enough context. It only points to agent_catalog as a prerequisite, but doesn't explain what the tool returns or how it fits into a workflow.
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 defined, so baseline score is 4. Description does not need to add parameter meaning, and it does not attempt to do so.
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 only provides a label 'L:READ' and category '交易', but no explicit verb or resource. Name suggests listing one-click repay, but description fails to confirm this, leaving purpose 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?
Description includes a prerequisite instruction '请先调用 agent_catalog', but does not clarify when to use this tool vs. alternatives or provide context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. '[L:READ]' hints at read-only operation but is ambiguous. No disclosure of pagination, rate limits, or behavior like what data is returned. The prerequisite to call agent_catalog is mentioned 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but cryptic, mixing symbols, Chinese, and English tags. It is not well-structured for an AI agent; it lacks clear sentences. Conciseness is positive but under-specification hurts usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should explain return value. It does not. The tool is for archived orders but no mention of date ranges or filtering beyond limit and instType. The prerequisite call to agent_catalog is not explained. Incomplete for a 2-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 coverage is 100% with descriptions for both parameters (instType and limit) in Chinese. The description does not add any additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'okx_get_orders_archive' clearly indicates retrieving archived orders. The description adds '[L:READ] CAT:[交易]' which suggests a read operation in trading, but lacks a specific verb. It is not a tautology but the description is not explicit enough to distinguish from siblings like 'okx_get_orders_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?
The description includes '→ 请先调用 agent_catalog' indicating a prerequisite to call another tool first, but does not explain when to use this tool versus alternatives (e.g., 'okx_get_orders_pending', 'okx_get_orders_history'). No differentiation from 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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. The tag '[L:READ]' indicates the tool is read-only, but there is no information about required authentication, rate limits, or what the response contains. The description lacks substantive behavioral details beyond this tag.
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 tags and a clear instruction. It avoids redundancy, but it is so sparse that it sacrifices substance. Still, it is concise with little waste.
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 has no parameters, no output schema, and no annotations, the description is the sole source of context. It fails to explain what the tool returns, when to use it, or how it fits among many sibling tools related to copy trading. The description is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so baseline is 4. The description does not add parameter-level meaning, but that is not needed. However, the description could have clarified the purpose of the tool despite no parameters, but for this dimension it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only contains tags '[L:READ]' and 'CAT:[策略-跟单]' and a prerequisite instruction. It does not explicitly state what data the tool retrieves or how it differs from similar tools like okx_get_copy_settings or okx_get_public_lead_traders. The core purpose of 'get public copy config' 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?
The description mentions '→ 请先调用 agent_catalog' as a prerequisite but provides no guidance on when to use this tool versus alternatives such as okx_get_copy_settings or okx_get_public_lead_traders. No context about usage scenarios is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only contains a cryptic '[L:READ]' label, which might imply read-only, but it's not explicit. No information about side effects, rate limits, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, achieving conciseness, but it is cryptic and poorly structured. The use of brackets and colons may be internal conventions but lacks clarity for an external agent.
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 a minimal, opaque description, the tool is inadequately documented. The agent has no sense of what the return data contains or how to use the result. The name provides some context, but the description fails to build on it.
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 (100% schema coverage), so the description naturally adds no value beyond the schema. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague, consisting of cryptic labels and a prerequisite instruction. It does not clearly state the verb and resource, forcing reliance on the tool name. The sibling tools include similar public data tools, and no differentiation is provided.
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 only instruction is to call agent_catalog first, which is a prerequisite, not usage context. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only reveals a read intent via '[L:READ]', but provides no other behavioral traits such as side effects, rate limits, or response format. 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 very short, which is concise, but lacks proper structure. It uses cryptic brackets and an arrow symbol without clear English exposition. It could be more readable while remaining brief.
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 at least clearly state its purpose and when to use it. It fails to do so, omitting essential context about what 'pending recurring orders' are and how this tool fits into the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to elaborate on parameters. Baseline score of 4 applies as there is no additional meaning required beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It includes a read label and a category hint, but fails to clearly convey that it retrieves pending recurring orders. The tool name provides more clarity than the description.
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 only gives a prerequisite instruction ('call agent_catalog first') but offers no guidance on when to use this tool versus its siblings (e.g., okx_get_recurring_orders_history). It lacks context for 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?
With no annotations provided, the description must fully disclose behavioral traits. The '[L:READ]' tag indicates a read-only operation, but no other behaviors (e.g., side effects, rate limits) are mentioned. This is insufficient given 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 very short, which is concise, but it lacks clarity. It includes structured tags that are informative, but the brevity comes at the cost of explaining the tool's function. A more balanced description would be better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide a complete understanding of the tool's purpose and usage. It fails to do so, leaving the agent with only a vague hint about prerequisites. The description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is trivially complete (100% coverage). The description adds no parameter information, but the baseline for zero parameters is 4, as no further meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It includes tags like '[L:READ]' and 'CAT:[策略-RFQ]' but does not clarify that it retrieves RFQ counterparties or what that entails. The purpose is implied by the name but not clearly communicated.
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 ('请先调用 agent_catalog'), but it does not explain when to use this tool versus alternatives. Without context on the tool's role or exclusions, the agent lacks guidance for proper invocation.
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 tag '[L:READ]' hints at read-only operation, but it doesn't disclose any behavioral traits (e.g., data scope, auth needs, 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?
Very short but cryptic due to tags and Chinese text. Not effectively front-loaded; the prerequisite is noted but core purpose is 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 no output schema and complex domain (RFQ trades), description is incomplete. It fails to explain what data the tool returns or how to interpret 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?
No parameters exist, so description does not need to add parameter info. Baseline 4 is appropriate as no additional semantics are required.
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 is cryptic with tags like '[L:READ]' and 'CAT:[策略-RFQ]', and a prerequisite to call agent_catalog. Core purpose of retrieving RFQ trades is not clearly stated.
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?
Only mentions a prerequisite ('please call agent_catalog first'), but no guidance on when to use this tool vs alternatives like okx_get_rfqs.
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 bears full responsibility but only indicates it's a read operation and for account. No details on what 'risk state' entails, whether it requires specific permissions, 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?
Extremely concise (one line) but at the expense of clarity. It includes a prerequisite note, but the brevity makes it cryptic. A longer description would be more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description does not explain what the tool returns or how the risk state is defined. The prerequisite is noted, but the core function is undefined.
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 the schema covers everything. The description adds no parameter info, but none is needed. Baseline is 4 for no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic codes like '[L:READ] CAT:[账户]' and fails to state a clear verb+resource. It does not explicitly say it retrieves the risk state. The prerequisite '请先调用 agent_catalog' adds confusion rather than 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 on when to use this tool versus siblings like okx_get_balance or okx_get_positions. The only hint is a prerequisite to call agent_catalog, but no context on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only indicates read-only via '[L:READ]' but fails to disclose other behavioral traits such as data scope (e.g., time range, filtering), idempotency, or rate limits. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one line) but lacks substantive detail. It is front-loaded with the read tag, but the crucial information about what the tool returns is missing. Conciseness does not compensate for incompleteness.
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 parameters, no output schema, and a simple tool, the description should at least explain what SFP orders are, the scope of history returned, and any prerequisites beyond agent_catalog. It fails to provide a complete picture, especially compared to similar tools like okx_get_orders_history.
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, so schema description coverage is 100%. Baseline for 0 params is 4. The description adds no parameter information, which is acceptable as there are none, but it also lacks return context. However, parameter semantics dimension does not penalize missing return info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague and relies on the tool name for purpose. It only states '[L:READ] CAT:[金融]' and instructs to call agent_catalog, but does not clearly explain what the tool does beyond being a read operation for SFP order 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. The only hint is to call agent_catalog first, which is a prerequisite, not a usage guideline. Lacks context for appropriate versus inappropriate usage compared to sibling tools like okx_get_orders_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only includes a '[L:READ]' tag hinting at read-only behavior. It does not disclose any other behavioral traits such as data volume, rate limits, or side effects. The agent is left guessing about what this tool might do beyond 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?
The description is extremely concise: a single line with relevant tags and a prerequisite note. It is front-loaded and lacks unnecessary verbiage, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the signal bots domain and the presence of many sibling tools (e.g., 'okx_get_signal_bots_pending', 'okx_get_signal_positions'), the description fails to explain what 'history' means, what the output looks like, or how it differs from related tools. It is insufficient for an agent to confidently select this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions in the schema). The tool description itself adds no additional parameter context, but according to the rubric, baseline is 3 when coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides tags ('[L:READ]', 'CAT:[策略-信号]') and a prerequisite note ('→ 请先调用 agent_catalog'), but does not explicitly state that this tool returns the history of signal bots. The name is somewhat clear, but the description adds minimal value 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?
The description instructs to call 'agent_catalog' first, which is a usage prerequisite, but it does not provide any guidance on when to use this tool versus alternatives like 'okx_get_signal_bots_pending' or 'okx_get_signal_positions'. There is no comparative 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 [L:READ] label hints at read-only behavior, which is useful, but there is no disclosure of other behavioral traits such as authentication, rate limits, or return format. The prerequisite is mentioned but 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 very concise (under 20 words) and uses a structured prefix for read-only and category. However, it could be 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 tool has parameters, no output schema, and many siblings, the description lacks details about return values, parameter usage, and when to use this tool over similar ones. The prerequisite is helpful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters described in Chinese. The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It only provides a category and a prerequisite, leaving the purpose to be inferred from the name. This is vague for an agent that may not understand the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a single usage guideline: call agent_catalog first. It does not differentiate when to use this tool over sibling spread tools like okx_get_spread_orders or okx_get_spread_orders_pending.
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. The '[L:READ]' label hints at a read-only operation, and the prerequisite note is useful, but there is no disclosure of other behavioral traits such as rate limits, idempotency, 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 and front-loaded with labels, but it is cryptic and requires interpretation. It could be equally concise yet more informative, e.g., 'Get the current OKX system time. Read-only. Prerequisite: Call agent_catalog first.'
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 (no parameters, no output schema), a minimal description could still be complete if it stated the purpose. The current description lacks a basic statement like 'Returns the system time' and relies on the name. The prerequisite instruction is a plus but insufficient.
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 (schema coverage 100%), and the description does not need to add semantics. The baseline for zero parameters is 4, and the description does not detract from it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic labels like '[L:READ]' and 'CAT:[公共]' and a prerequisite instruction '请先调用 agent_catalog' but does not explicitly state that the tool returns the OKX system time. The name is clear, but the description fails to articulate the purpose in plain language.
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 to call agent_catalog first, but does not provide any guidance on when to use this tool versus siblings like okx_get_system_status or other public tools. No alternative or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only indicates it is a read operation. There is no disclosure of behavioral traits such as whether it performs network calls, changes state, or has rate limits. The minimal '[L:READ]' label 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 extremely concise, consisting of a single line with brackets and Chinese. While it is short, it sacrifices clarity for brevity and relies on coded labels that may confuse the agent.
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, no output schema, and a simple intended function, the description should still clearly state its purpose and behavior. It fails to do so, leaving the agent without sufficient context to decide when and why to use it.
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 schema coverage is 100% by default. The description adds no parameter information, but per the guidelines, a baseline of 4 is appropriate for tools with no parameters. The instruction to call agent_catalog is unrelated to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic labels '[L:READ]' and 'CAT:[预测]' but fails to state that this tool checks the heartbeat status of the predictions service. The purpose is vague and does not clearly distinguish from sibling prediction 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 advises to call 'agent_catalog' first, implying a prerequisite, but provides no guidance on when to use this tool versus alternatives like 'okx_predictions_list_events' or 'okx_predictions_get_event'. Usage context is unclear.
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 does disclose that the tool is read-only ('[L:READ]') and implies a prerequisite, which adds some context. However, it lacks details on authorization, rate limits, or consequences of not following the prerequisite.
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 but cryptic and poorly structured. It consists of tags and a directive without forming a coherent sentence. While concise, it fails to efficiently convey the tool's 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 simplicity of the tool (one parameter, no output schema), the description is incomplete. It does not explain what the tool returns, how it relates to predictions, or why 'agent_catalog' must be called first. An agent would lack sufficient 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% for the single parameter 'instId', and the description does not add any additional meaning beyond what the schema provides. The description mentions 'YES/NO 资产的 instId' but this is redundant with the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is cryptic, using tags like '[L:READ]' and 'CAT:[预测]' without clearly stating the tool's function. It does not specify that it retrieves a ticker for predictions; instead, it directs users to call 'agent_catalog' first. The purpose is not clearly communicated.
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 only states a prerequisite ('请先调用 agent_catalog') but does not indicate when to use this tool versus sibling tools like 'okx_get_ticker' or 'okx_predictions_get_market'. No guidance on context or alternatives is provided.
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?
The description provides almost no behavioral details beyond the '[L:WRITE]' tag indicating a write. There are no annotations to supplement. It does not disclose effects (e.g., position removed, potential losses), reversibility, authorization needs, or rate limits. The agent is left in the dark about what this operation does.
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 (one line). It uses structured tags [L:WRITE] and CAT: for categorization. However, the brevity sacrifices completeness and clarity, as critical behavioral information is omitted. It is front-loaded but not optimally structured for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that closes a grid position (a potentially irreversible action), the description is severely lacking. It fails to explain the operation's implications, return values, or required preconditions beyond calling agent_catalog. With no output schema and minimal description, the agent cannot properly assess the tool's suitability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with its own descriptions, so the baseline is 3. The tool description adds no further meaning to the parameters (algoId, algoOrdType) beyond what the schema already provides. No extra context or formatting hints.
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 does not explicitly state 'close a grid position' beyond the tool name. The 'CAT:[策略-网格]' and '[L:WRITE]' tags indicate it's a write operation in the grid strategy category, but the core action is implied rather than stated. This confuses the purpose for an agent unfamiliar with the 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 includes a prerequisite ('→ 请先调用 agent_catalog'), which provides some usage context. However, it lacks guidance on when to use this tool vs alternatives (e.g., stop_grid_order), and does not state when not to use it. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only includes a '[L:READ]' tag indicating read-only, but does not disclose any behavioral traits such as authentication requirements, rate limits, data freshness, or potential side effects. The description carries full burden but adds minimal value.
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, consisting of a single line with tags and a prerequisite instruction. While it is short, it is not verbose, and the structure is clear. However, it could be more informative without increasing length significantly.
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 parameters, the description fails to explain what the tool returns, how it relates to similar tools like 'okx_get_account_bills', or any contextual details about data scope (e.g., time range, filtering). The description is insufficient for an agent to confidently use the 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 tool has no parameters (0 parameters, schema coverage 100% trivially). The description does not need to add parameter information, and the lack of parameters is clear from the schema. The description is adequate in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates a read operation for 'account bills archive' but does not explain what 'bills archive' means or how it differs from the sibling tool 'okx_get_account_bills'. The purpose is vague and lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to call 'agent_catalog' first, suggesting a prerequisite, but does not provide context on when to use this tool versus alternatives like 'okx_get_account_bills' or others in the account category. No exclusions or clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '[L:READ]' tag hints at a read-only operation, but no annotations are provided. The description lacks details about authentication, rate limits, or side effects, which is a significant gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but poorly structured. It is not front-loaded with a clear statement of purpose; instead, it uses cryptic tags and a prerequisite instruction that may confuse an AI agent.
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 severely incomplete. It does not explain return values, error behavior, or any context about account balance retrieval. Given the tool's simplicity (1 optional parameter) and no output schema, the description should at least state 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?
The input schema has 100% description coverage for the 'ccy' parameter, explaining it in Chinese. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses tags like '[L:READ]' and 'CAT:[账户]' but does not explicitly state that the tool retrieves account balance. The tool name 'okx_get_balance' and the input schema with 'ccy' parameter imply the purpose, so it is minimally adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite instruction '→ 请先调用 agent_catalog', which provides some usage context. However, it does not compare with sibling tools like 'okx_get_asset_balances' or specify 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. '[L:READ]' hints at a read-only operation, but there is no disclosure of permissions, rate limits, or whether it returns addresses for all chains. The description is minimal and does not add substantial behavioral context beyond the read hint.
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 one line, very concise, but includes fragmented tags and Chinese text. It is not well-structured for an English-speaking agent, but it is not verbose. Conciseness is acceptable but lacks 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 a simple tool with one parameter and no output schema, the description is incomplete. It does not mention that the deposit address might depend on the network or that it returns a single address. The sibling list includes many related tools, but the description fails to provide sufficient context for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 required parameter 'ccy' with a description in Chinese stating 'currency, e.g., USDT, BTC, ETH'. Schema coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.
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 name 'okx_get_deposit_address' indicates it retrieves a deposit address. The description adds '[L:READ]' and category '[资金]' but does not explicitly state that the tool returns the address for a given currency. The purpose is moderately clear but lacks specificity about the output format or 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 instructs to call 'agent_catalog' first, implying a prerequisite, but provides no guidance on when to use this tool over alternatives like 'okx_get_deposit_history' or 'okx_get_deposit_lightning'. No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only contains the tag '[L:READ]' which hints at a read-only operation. It discloses no other behavioral traits such as side effects, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but not well-structured; it uses tags and a prerequisite note without front-loading the core purpose. It is concise but at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling tools and the lack of an output schema, the description is insufficient. The prerequisite to call agent_catalog introduces a dependency that is not explained, leaving the tool incomplete 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 100%, so parameters are documented. The description adds no additional meaning beyond the schema definitions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses tags like '[L:READ] CAT:[资金]' which vaguely imply reading deposit history, but it does not explicitly state the tool's purpose in natural language. The instruction to call agent_catalog first further obscures the primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('请先调用 agent_catalog'), providing some guidance on usage order. However, it offers no differentiation among the many sibling tools, leaving the agent uncertain 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only states L:READ (likely read-only) but does not disclose any behavioral traits such as rate limits, data scope, or dependencies beyond the catalog call. Minimal value added.
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 but not effectively concise. It omits essential details at the cost of clarity. It front-loads the READ hint and category but leaves the tool's purpose ambiguous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description is incomplete, failing to explain what data is returned, how to interpret the event series, or how it fits among numerous related sibling tools. The prerequisite hint is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), so baseline is 3. The description adds no parameter-related information, which is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague, only indicating it is a read operation in the '预测' (prediction) category and instructing to call agent_catalog first. It fails to specify what an event series is or how it differs from sibling tools like okx_get_event_events.
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 clear prerequisite ('请先调用 agent_catalog'), but offers no guidance on when to use this tool versus alternatives, no exclusions, and no context about its role in a workflow.
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. The description includes [L:READ] which implies read-only, but this is not a formal annotation. No other behavioral traits are disclosed, such as rate limits or response structure.
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, which can be considered concise, but it omits essential information. It is not well-structured for an agent to understand the tool's 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 simplicity (one parameter, no output schema), the description should at least state the purpose and output. It fails to provide a complete picture, relying solely on the tool name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for the single parameter instId. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only contains a tag [L:READ] and a prerequisite. The tool name suggests it retrieves the funding rate, but the description itself provides no clarity.
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 usage note '请先调用 agent_catalog' (call agent_catalog first), which is a helpful guideline. However, it lacks details 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.
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 indicates a read operation via [L:READ], but lacks details on what the summary contains, data aggregation, rate limits, or side effects. The note about agent_catalog is helpful but 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 very short but uses mixed Chinese/English and cryptic tags. While concise, it may confuse non-Chinese agents and lacks clear 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, the description should explain return values. It does not describe what data is returned (e.g., rates, currencies). The simple optional parameter is insufficient for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the 'ccy' parameter. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic Chinese tags ([L:READ], CAT:[统计]) and a note to call agent_catalog, without explicitly stating the tool's function. The purpose is only implied by the name 'okx_get_lending_rate_summary', which may not be clear to all AI agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite (call agent_catalog first), which provides some guidance. However, it does not specify when to use this tool vs sibling tools like okx_get_lending_rate_history or okx_set_lending_rate, missing differentiation.
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. The 'L:READ' tag suggests read-only, but no further behavior (e.g., rate limits, data range, response structure) is disclosed. This is insufficient for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line) but lacks substantial content beyond tags and a prerequisite. It earns its place but sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and minimal description. The tool has 3 parameters (1 required) and is in a context of many similar tools. The description does not provide enough information for an agent to confidently use it without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description in Chinese. The description does not add extra semantic meaning beyond the schema (e.g., examples or formatting hints). Baseline 3 is appropriate given high coverage.
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 'L:READ' and 'CAT:[Statistics]' but does not explicitly state that the tool retrieves the long/short ratio for a given currency. The name is clear, but the description relies on it. Sibling tools like okx_get_top_trader_long_short_ratio exist, but no differentiation is provided.
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 '→ 请先调用 agent_catalog' (please call agent_catalog first), indicating a prerequisite. However, it gives no guidance on when to use this tool vs. alternatives like okx_get_contracts_long_short_ratio or okx_get_long_short_account_ratio.
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 notes the tool is a read operation. It lacks details on authentication, rate limits, side effects, or what the history data contains.
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 brief (one line) but is under-specified; it sacrifices clarity for brevity and does not provide enough information to guide tool use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description fails to explain the return format or usage context. It only gives a prerequisite, leaving significant gaps for a tool with zero parameters.
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 no parameters, the schema is fully descriptive. The description does not add parameter info, but the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a category tag and a prerequisite instruction, not a clear statement of the tool's function. It does not explicitly state that it retrieves one-click repay history, nor does it distinguish 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to call agent_catalog first, implying a prerequisite but not offering guidance on when to use this tool versus alternatives like get_one_click_repay_list or get_borrow_repay_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It includes a read-only hint via '[L:READ]', but does not disclose other behaviors such as pagination limits, authentication requirements, potential performance impacts, or whether results are sorted by time. The description is insufficient for understanding tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (single line), which is efficient but comes at the cost of completeness. It front-loads a metadata tag and prerequisite, but lacks explanatory detail for a tool with moderate 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?
The tool has no output schema and 3 parameters, but the description does not explain return values, ordering, or any limitations. The prerequisite note is useful but overall completeness is low; an agent would lack key information to confidently use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—all three parameters (limit, instId, instType) are described in the schema. The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate as schema is adequate.
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 includes '[L:READ]' indicating a read operation, and the name 'get_positions_history' implies retrieving historical positions. However, the description does not explicitly state what data is returned or how it differs from current positions, leaving the purpose somewhat implied.
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 instructs to call 'agent_catalog' first, which is a usage guideline, but it lacks context on when to use this tool vs. alternatives like okx_get_positions or other history tools. No comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states a read operation via '[L:READ]' but does not mention authentication requirements, rate limits, or what the response contains. No output schema exists to compensate.
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 brief—two tags and a prerequisite note. It is concise and front-loaded but somewhat under-informative. It earns a high score for efficiency, though more substance would improve it.
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 tool's specific purpose (recurring orders history), the description fails to explain what recurring orders are, what data the tool returns, or how to interpret the results. It relies heavily on the prerequisite call to 'agent_catalog' and is thus incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so parameter documentation is unnecessary. With 0 parameters, the baseline is 4, and the description adds no parameter information, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags '[L:READ]' and 'CAT:[策略-网格]' indicating a read operation on grid strategies, but does not explicitly state that the tool retrieves history of recurring orders. The purpose is vague and does not distinguish it from sibling recurring order tools like 'okx_get_recurring_orders_pending'.
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 instructs to call 'agent_catalog' first, which is a prerequisite, but provides no guidance on when to use this tool versus alternatives such as 'okx_get_recurring_orders_pending' or 'okx_get_recurring_sub_orders'.
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 includes the '[L:READ]' tag, hinting at read-only behavior. No disclosure of destructive potential, authorization needs, or side effects. Minimal behavioral context beyond the tag.
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 extremely short, but no wasted words. However, it is under-specified for the tool's complexity, failing to convey essential information. Acceptable conciseness 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?
With no output schema, no annotations, and only 2 parameters, the description lacks completeness. It does not explain return values, pagination, or typical use context. The prerequisite to call agent_catalog is helpful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions in the schema. Description adds no parameter-level information; baseline 3 is appropriate as schema already documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description includes '[L:READ]' indicating a read operation, but does not explicitly state the verb or resource. The name 'get_recurring_sub_orders' provides purpose, but the description adds little clarity. It vaguely categorizes as '策略-网格' (Strategy-Grid) without differentiation 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to 'call agent_catalog first', which is a prerequisite but not usage guidance. No information on when to use this tool versus alternatives, no exclusions or context for decision-making.
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 includes a read hint '[L:READ]' and a category 'CAT:[公共]', but lacks details on side effects, dependencies, or return characteristics. The prerequisite hint is present but 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of two fragments. It is concise but at the expense of clarity. It includes a useful prerequisite instruction, but the overall lack of structure and completeness 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 large number of sibling tools, no output schema, and only one parameter, the description fails to provide sufficient context. It does not explain what the tool returns, how it differs from similar OKX tools, or what the prerequisite entails. The description is incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already provides a clear description of the 'instType' parameter with enum values and their meanings. The tool description adds no additional semantic value beyond what the schema offers, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague: it only indicates the tool is read-only and requires a prior call to 'agent_catalog', but does not explain what 'underlying' means or what the tool returns. The name suggests it retrieves underlying information for OKX instruments, but the purpose is not clearly stated.
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 prerequisite ('call agent_catalog first'), which is a useful guideline. However, it does not specify when to use this tool versus alternatives among the many sibling tools, nor does it give any exclusion 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 are provided, and the description only gives a category and prerequisite. It does not disclose any behavioral traits such as what data is returned, pagination, rate limits, or side effects. The tool is likely safe (read), but transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line) but includes a tag and a prerequisite. It is concise but arguably too sparse for a tool with two parameters and no output schema. It does not waste words but also does not earn its place by being 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 complexity of the tool ecosystem and the lack of output schema, the description is insufficient. It does not explain what trades are returned, the scope of data, or how it relates to other predictions tools. The prerequisite to 'agent_catalog' hints at a workflow but is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions in Chinese, so the schema documents them adequately. The description adds no additional meaning beyond the schema; it merely provides a context tag. Baseline 3 is appropriate.
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 includes a '[L:READ]' tag indicating a read operation and 'CAT:[预测]' suggesting predictions category, but does not explicitly state that the tool retrieves trades for predictions. The tool name implies it, but the description is vague; a user might infer it gets trades but not clearly.
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 instructs to call 'agent_catalog' first, which is a prerequisite, but provides no guidance on when to use this tool versus siblings like 'okx_predictions_ticker' or 'okx_predictions_get_order'. No differentiation or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description includes '[L:READ]' which may contradict the 'reset' action (likely a write operation), but it's ambiguous. The description does not disclose whether the operation is destructive, what happens to existing keys, authentication requirements, or rate limits. Behavioral transparency is poor.
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 line) but includes a prerequisite. It is not particularly front-loaded with the core action. While concise, it lacks substance and could be clearer.
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 no annotations, the description should provide more context about the effect, return values, and side effects. The prerequisite is noted, but overall completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with descriptions in Chinese for all 5 parameters. The tool description does not add any parameter-level information beyond what the schema already provides. Baseline score of 3 is appropriate as the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'okx_reset_subaccount_api_key' suggests resetting an API key, but the description only provides a category and a prerequisite call. It does not explicitly state what the tool does or what 'reset' implies (e.g., regenerate key, revoke permissions). The purpose is vague and relies heavily on the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes '请先调用 agent_catalog' (call agent_catalog first), providing a prerequisite. However, it does not specify when to use this tool versus siblings like okx_create_subaccount_api_key, okx_delete_subaccount_api_key, or okx_get_subaccount_api_key. No alternatives or exclusion criteria 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?
With no annotations, the description carries the full burden, but it offers minimal behavioral context: only a [L:READ] tag implying non-destructive nature. No side effects, authentication, rate limits, or state management are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line) and front-loaded with the read hint and category, but the structure is cryptic and lacks proper sentences. It sacrifices clarity 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 of a WebSocket subscription tool with 33 channels and 3 parameters, the description is grossly incomplete. It fails to explain subscription lifecycle, how to unsubscribe, or how this tool relates to sibling websocket 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 is 3. The description does not add any extra meaning beyond the schema's parameter descriptions. It provides no insight into parameter interactions or formatting nuances.
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 indicates it's a read operation for market data WebSocket (行情-WS) and suggests a prerequisite (agent_catalog), but does not explicitly state the tool's function of subscribing to WebSocket channels. This vagueness leaves room for confusion, especially when compared to sibling tools like okx_ws_subscribe_private.
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 okx_ws_events or okx_ws_subscribe_private. The only hint is to call agent_catalog first, which is a prerequisite but not a usage condition.
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 description must convey behavior. It only labels the tool as 'READ', which is insufficient; there is no mention of side effects, permissions, rate limits, or return characteristics.
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 very short but at the cost of omitting essential information. It is concise but not complete enough to be effective.
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 a single parameter and no output schema, the description still fails to explain what the event is, how responses are structured, or how this tool relates to other outcomes 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% with a description for eventId (事件ID). Baseline is 3 per guidelines, and the tool description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Name 'outcomes_get_event' suggests retrieving an event, and description includes '[L:READ]' indicating a read operation. However, description is cryptic and does not clearly articulate the tool's purpose 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?
Only usage guidance is '请先调用 agent_catalog', implying a prerequisite but providing no when-to-use or comparison with sibling tools like outcomes_list_events or outcomes_get_market.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only indicates 'read' via '[L:READ]' but omits details about rate limits, side effects, return format, or required permissions. For a tool with 3 parameters and 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines), but the use of cryptic tags like 'CAT:[预测]' and Chinese text '请先调用 agent_catalog' reduces clarity for an English-centric AI. It is front-loaded but at the expense of comprehensibility. Every character is present 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 tool has 3 parameters, no output schema, and no annotations, the description should provide more context about what an orderbook represents for prediction markets, how outcome and size interact, and what the return value looks like. The prerequisite 'agent_catalog' is mentioned but not explained. The description falls short of being complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any meaning beyond what the schema already provides for the three parameters (marketId, outcome, size). It fails to explain how outcome 'YES/NO' relates to prediction markets or how size affects the depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic tags '[L:READ] CAT:[预测]' and a prerequisite note, but does not clearly state that the tool retrieves the orderbook for prediction outcomes. While the name is indicative, the description fails to differentiate from sibling tools like 'okx_get_orderbook', leaving ambiguity about the specific domain (prediction vs. spot/futures).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite 'please call agent_catalog first', which provides some guidance on when to use this tool. However, it does not specify when to prefer this over alternatives like 'outcomes_get_ticker' or 'okx_get_orderbook', nor does it mention any exclusions. The guidance is minimal but not misleading.
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 carry the transparency burden. It only hints at a read operation via '[L:READ]' but does not disclose any behavioral traits such as side effects, rate limits, or what 'events' entail.
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 at the cost of clarity. It uses tags and a prerequisite note, but the lack of structure and informative content 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?
The tool has no output schema and minimal description. It does not explain what the tool returns, how events work, or the full usage context, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter 'subscriptionId' is described in the schema. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[链上] | → 请先调用 agent_catalog' is vague; it does not explicitly state that the tool retrieves events. The name 'xlayer_get_events' implies the purpose, but the description lacks a clear verb-resource statement.
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 indicates a prerequisite ('请先调用 agent_catalog'), providing some guidance on when to use the tool. However, no information on when not to use it or alternatives is given, limiting its helpfulness.
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 includes a 'READ' hint, but otherwise no details on side effects, data retrieval scope, or authentication needs. For a tool with no parameters, the description is minimal and lacks 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 (one line), but its structure uses cryptic tags and Chinese characters without clear formatting. It is not well-organized for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description is missing information about what the tool returns (e.g., list structure) and when it should be used beyond prerequisites. The cryptic nature leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter documentation. A baseline score of 4 is appropriate since no parameters exist, and the description does not mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description relies on the tool name ('okx_get_affiliate_link_list') to hint at retrieving an affiliate link list, but the description itself is cryptic with tags like '[L:READ] CAT:[推广]' and does not explicitly state the tool's purpose. It is not a tautology but lacks specificity and clarity.
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 instructs to call 'agent_catalog' first, providing a prerequisite for use. However, it does not explain when to use this tool over siblings or provide context on alternatives, leaving the agent without complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only notes a read operation via '[L:READ]' and a category, but does not disclose any behavioral traits such as rate limits, data freshness, or side effects. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single line with bracket notation. It efficiently communicates the category and a prerequisite. No words are wasted, though the structure is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the tool returns. Given the complexity of retrieving contract long/short ratios, the description should provide information about the response format or data fields. The current description is incomplete for an agent to fully understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter (ccy, end, begin) having a description in the input schema. The description does not add any additional meaning beyond the schema, so baseline score of 3 is appropriate.
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 tool name 'okx_get_contracts_long_short_ratio' clearly indicates it retrieves the long/short ratio for contracts. However, the description '[L:READ] CAT:[统计] | → 请先调用 agent_catalog' does not explicitly state the purpose; it only adds a category and a prerequisite. The purpose is implied but not clarified 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?
The description instructs to call 'agent_catalog' first, providing some context about a prerequisite. However, there is no guidance on when to use this tool versus numerous sibling tools like 'okx_get_long_short_ratio' or 'okx_get_contract_trader_ls_ratio'. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'L:READ', indicating a read operation, but discloses no other behavioral traits such as idempotency, rate limits, or side effects. This minimal disclosure is insufficient for an agent to understand the tool's behavior fully.
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, but at the expense of clarity. The '[L:READ]' prefix is helpful, but the rest is cryptic and lacks structured information. The extreme brevity is not considered effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description fails to explain what 'discount info' entails, what the output looks like, or how to interpret it. The agent would lack 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty with 100% coverage. According to guidelines, 0 parameters yields a baseline score of 4, as no additional parameter description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates it's a read operation in the '公共' (public) category and advises calling agent_catalog first, but does not specify what discount info is retrieved or for what purpose. The purpose is vague and leaves the agent uncertain about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('请先调用 agent_catalog'), which provides some guidance on when to use this tool. However, it offers no comparison to sibling tools or conditions for alternative choices, limiting its usefulness beyond the single directive.
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 includes a read hint and category. There is no disclosure of behavioral traits like side effects, auth needs, or rate limits, leaving the agent under-informed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single line, front-loading the read tag and category. Every element earns its place with 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?
With no output schema and minimal description, the tool lacks completeness. An agent cannot determine what data is returned or how to interpret results, especially given the large number of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100%. Baseline for zero parameters is 4; the description adds no param info which is acceptable since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a category tag and indicates a read operation but lacks a clear verb and resource. It does not explicitly state what the tool does, leaving ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to call 'agent_catalog' first, providing a sequence hint, but does not explain when to use this tool versus alternatives or any prerequisites beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It includes '[L:READ]' hinting at read-only nature, but lacks details on side effects, permissions, rate limits, or data freshness. The agent has little to infer about the tool's behavior beyond it being 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 extremely short, but at the cost of clarity. It front-loads code labels and Chinese text. While concise, it sacrifices comprehensibility for an English-speaking AI agent. A better structure would be a plain English sentence stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description should at least state what it returns (e.g., 'Lists available fiat deposit methods'). It only provides a prerequisite and a category label, leaving the agent to guess the output. This is incomplete for an effective tool definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to document. The description does not need to add parameter semantics. The baseline score of 4 applies because the schema coverage is trivially 100% and no additional explanation is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic labels like '[L:READ]' and Chinese text, and the name 'okx_get_fiat_deposit_methods' suggests listing deposit methods, but the description does not explicitly state that. It fails to clearly communicate the tool's core purpose to an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite instruction '→ 请先调用 agent_catalog', which is useful guidance. However, it does not specify when to use this tool over sibling tools like okx_get_fiat_deposit or okx_get_fiat_deposit_orders, nor does it explain 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?
The description marks the tool as '[L:READ]' indicating a read-only operation, which is a behavioral trait. With no annotations provided, the description carries the full burden, but it does not disclose authentication needs, rate limits, or other side effects beyond the read hint. This leaves significant gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single line with metadata tags and a prerequisite instruction. While efficient, it could be clearer with natural language phrasing. The structure uses brackets and an arrow, which is compact but not fully intuitive.
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 domain (lead positions in copy trading) and the presence of many sibling tools, the description lacks context about what lead positions are, the output format (no output schema), and when this tool is appropriate. The prerequisite instruction is helpful but insufficient for complete 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?
The input schema has full description coverage (100%) for the single optional parameter instType, including its enum values and a note that leaving it blank returns all. The description adds no additional parameter information, so baseline score of 3 is appropriate since the schema already handles semantics.
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 name 'okx_get_my_lead_positions' implies retrieving the user's lead positions, and the description adds a category tag suggesting copy trading. However, it does not explicitly state what the tool does or differentiate it from siblings like okx_get_lead_trader_positions, making the purpose somewhat 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?
The description includes a prerequisite instruction to call agent_catalog first, which provides one usage guideline. However, it does not specify when to use this tool versus alternatives (e.g., okx_get_my_lead_history) or when not to use it, leaving the agent with minimal decision support.
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 it is a read operation via [L:READ] and a category, but omits details about data returned, pagination, authentication requirements, or any side effects. This is insufficient for an agent to fully understand 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 extremely concise, using structured tags and a clear prerequisite note. It is front-loaded and avoids verbosity, though it sacrifices depth 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 tool has one optional parameter and no output schema or annotations, the description should provide more context about what RFQs are, how the state filter affects results, and return format. The prerequisite is helpful but overall completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions and enums for the single parameter. The description adds no additional meaning, aligning with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as reading RFQs (Request for Quotes) with a category tag, but it does not clearly specify the scope (e.g., user's own RFQs, all pending, etc.) or differentiate it from siblings like okx_get_quotes. It is adequate but lacks precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite instruction to call agent_catalog first, which provides some guidance on order of use. However, it offers no context on when to use this tool versus alternatives like okx_get_rfq_trades or okx_get_quotes, and no scenarios of applicability.
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 indicates the tool is a read operation ('[L:READ]'), which conveys it is non-destructive. However, with no annotations, it lacks further behavioral details such as idempotency, rate limits, or return value characteristics.
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 at the expense of clarity. It front-loads a read label and category, but the single sentence could be improved by adding purpose and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, no output schema), the description could still benefit from explaining what 'SFP products' are, what the tool returns, and how to use the results. The prerequisite hint is insufficient for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. Per guidelines, baseline 4 is appropriate since no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague, stating only '[L:READ] CAT:[金融]' and a prerequisite to call agent_catalog. It does not clearly state what the tool retrieves or how it differs from other tools, leaving the purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite '→ 请先调用 agent_catalog', which provides some guidance, but it offers no information on when to use this tool versus alternatives among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only labels the tool as L:READ (not a standard annotation) and provides no details on behavior, such as what the archive contains, pagination, rate limits, or whether it is destructive. Minimal 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?
The description is very short (one line with labels) and front-loaded with key identifiers. 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 large set of sibling spread tools, the description fails to clarify the difference between this 'archive' tool and others like okx_get_spread_orders_history. It does not explain return values or the nature of the archive, and the prerequisite is vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('sprdId') with a description ('价差合约ID'), and schema coverage is 100%. The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 indicates it is a read operation (L:READ) and categorizes it under '策略-价差' (strategy-spread), but it does not clearly state what data it retrieves (historical archived spread orders). The name suggests history, but the description is 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?
It mentions a prerequisite ('请先调用 agent_catalog') but does not specify when to use this tool over siblings like okx_get_spread_orders_history or okx_get_spread_orders_pending. No when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only conveys a read hint ([L:READ]) but discloses no behaviors such as return format, data scope, or side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with no redundant information. It is front-loaded with tags and a prerequisite. However, it could be more informative 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 the large set of sibling tools and lack of output schema, the description is significantly incomplete. It does not clarify what statistics are returned, for which coins, or how to interpret the output. The prerequisite to call agent_catalog implies needed context, but the tool itself is under-described.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, so schema coverage is 100%. The description adds no parameter information, but as there are no parameters, baseline is 3. The mention of 'agent_catalog' is not parameter-related.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '[L:READ] CAT:[统计]' hinting at a read operation and statistics, but fails to specify a clear verb and resource. It does not distinguish from sibling tools like okx_get_ticker or okx_get_system_status, leaving the tool's exact function ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('请先调用 agent_catalog'), providing some usage guidance. However, it does not specify when to use this tool versus alternatives, nor does it give exclusions or detailed context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only indicates read-only via [L:READ] but lacks details on authentication, rate limits, or response behavior. The description is insufficient for understanding the tool's actions beyond being 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 very short but uses cryptic notation and Chinese. It is not well-structured or fully self-contained. While concise, it sacrifices clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It does not explain what the tool returns or provide sufficient context for correct invocation. A tool with zero parameters typically requires clarity on its output.
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, and the schema coverage is 100%. The description does not add parameter meaning, but with zero parameters, the baseline is 4 as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is vague and does not clearly state the tool's purpose. It includes a read label and category tag but does not explicitly say 'list sub-affiliates'. The name provides some clue, but the description fails to articulate the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite instruction to call agent_catalog first, which provides some usage guidance. However, it does not specify when to use this tool versus alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only notes the tool is a read operation ('L:READ') but does not disclose any behavioral traits such as required permissions, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise but at the expense of clarity. It uses cryptic tags and does not explain the tool's purpose in plain language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (no parameters), the description fails to explain what the balance represents or how to interpret the output. The prerequisite to agent_catalog is noted, but overall completeness is low.
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 100% schema coverage, so the description need not add parameter details. It does not add any parameter info, but this is acceptable given the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a read hint and category but does not specify the resource or action. It mentions 'balance' in the name but the description only gives a vague category and a prerequisite call to agent_catalog.
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 explicitly instructs to call agent_catalog first, which is a usage prerequisite. However, no guidance on when to use this tool vs. alternatives like okx_get_balance 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?
The [L:READ] tag indicates read-only behavior, but without annotations, the description should disclose more behavioral traits. It does not mention authentication, rate limits, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but uses non-English text and brackets, making it less clear for an English-speaking audience. It could be more concise and standardized.
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 OKX predictions and the lack of output schema and annotations, the description is incomplete. It does not explain what the tool returns or the nature of event markets.
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 adds no information beyond the input schema. The schema already describes eventId as required; the description only adds a prerequisite call but not parameter detail.
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 indicates a read operation for event markets in the predictions category, but it uses Chinese and is not explicit about the result. It does not distinguish from sibling tools like okx_predictions_get_event.
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 to call agent_catalog first, but provides no guidance on 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 are provided, so the description must disclose behavioral traits. The '[L:READ]' label hints at read-only behavior, but it is not standard or explicit. The description does not clarify whether the tool is destructive, requires authentication, or has rate limits. For a read-like tool, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short segments. It front-loads the read hint and category. However, it could be slightly more structured by including a clear verb and resource. Despite this, it is not overly verbose and every part 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 of sibling tools (many prediction-related) and no output schema, the description should explain what the tool returns and how it fits into workflows. The prerequisite to call agent_catalog is helpful but insufficient. The tool's return value is not described, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the only parameter 'marketId' has a description '市场ID，必填' (Market ID, required). The tool description adds no additional meaning to the parameter beyond what the schema already provides. Therefore, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '[L:READ] CAT:[预测] | → 请先调用 agent_catalog' does not clearly state the tool's purpose. 'CAT:[预测]' indicates a category but no verb or resource. The tool name 'okx_predictions_get_market' implies retrieving a prediction market, but the description fails to explicitly confirm that. It is vague and relies on inference.
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 instructs to call agent_catalog first, which provides some usage context as a prerequisite. However, it does not specify when to use this tool versus alternatives like okx_predictions_get_event or outcomes_get_market, nor does it mention when not to use it. The guidance is minimal but present.
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 marks the tool as a write operation ('[L:WRITE]') but provides no detail on the effects of stopping a signal bot (e.g., whether positions are closed, orders cancelled). With no annotations, this lack of behavioral context 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 extremely concise, consisting of a single line that front-loads the category and operation type. While it lacks thoroughness, it avoids unnecessary 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?
With one parameter, no output schema, and no annotations, the description does not cover expected responses, error conditions, or the full effect of the operation. The prerequisite hint is helpful but insufficient for complete 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?
The schema already describes the single parameter 'algoId' with a Chinese description. The tool description adds no further parameter details but hints that the ID can be obtained from agent_catalog. Given 100% schema coverage, this baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides a category label and a prerequisite instruction. It does not explicitly state that the tool stops a signal bot; the purpose is only implied by the tool name. This vagueness hampers quick understanding.
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 '请先调用 agent_catalog' as a prerequisite, giving a hint on when to use this tool. However, it does not differentiate from alternative tools or specify when not to use it. The guidance is minimal but present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It merely contains [L:WRITE] hinting at a write operation but does not mention authorization needs, rate limits, what happens during the transfer (e.g., if funds are deducted immediately), or any side effects. The description is insufficient for an agent to understand 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 very short (one line), which is concise but at the expense of clarity. It uses brackets and arrow notation that may be cryptic. It is structured but lacks explanatory power.
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 transfer tool with four required parameters and no output schema, the description is far from complete. It omits what to do after the transfer, how to check status, and does not reference any sibling tools. The prerequisite to call agent_catalog is present but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with descriptions and enums for from/to, so baseline is 3. The description adds no additional meaning beyond what the schema already provides, but it does not detract either.
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 name 'okx_transfer' clearly indicates a transfer operation, and the schema parameters (from/to account codes) reinforce that it transfers funds between accounts. The description includes CAT:[资金] which means 'funds' in Chinese, adding a category hint. However, the description does not explicitly state the purpose in plain language, relying on the name and schema.
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 only provides a prerequisite ('请先调用 agent_catalog' or 'please call agent_catalog first') but does not explain when to use this tool versus alternatives like okx_get_transfer_state or okx_transfer_subaccount. No guidance on when not to use it or in which scenarios it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The [L:READ] tag indicates a read operation, which adds some behavioral context. However, no annotations are provided, and the description does not disclose other behaviors such as persistence effects, rate limits, or error conditions. The description is too minimal to fully inform 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 very concise, consisting of a single line with key tags and a prerequisite note. It is front-loaded with helpful categorization. While short, it conveys essential metadata efficiently without unnecessary 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?
Despite the high schema coverage, the description lacks completeness for the tool's overall purpose. It does not explain the subscription behavior, return values (no output schema), or how it integrates with the 'agent_catalog' prerequisite. A 3-param tool needs more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already explains the parameters. The description adds no additional meaning beyond what the schema provides, resulting in a baseline score of 3 as per the rubric for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses tags like [L:READ] and CAT:[链上] but does not clearly state the tool's action. The name 'subscribe' suggests subscription functionality, but the description fails to explain what is being subscribed to or how it works. It is vague and requires inference.
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 '请先调用 agent_catalog', which provides a prerequisite ordering instruction. However, it does not compare this tool to siblings or clarify when to use it versus other tools, leaving the agent without explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a '[L:READ]' tag hinting at read-only behavior, but since no annotations are provided, this carries the burden. It does not disclose other traits like required permissions, rate limits, or state changes.
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 and uses tags for categorization. It is front-loaded with key information, but the formatting (brackets and colons) is somewhat noisy.
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, and no parameter descriptions, the description fails to explain return format, pagination, or the meaning of 'optimal.' It is insufficient 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.
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 three performance metrics (return rate, win rate, drawdown), but only two align with sortBy options (pnl, winRate). The topN and instType parameters are unaddressed, leading to partial 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 filters best lead traders by return rate, win rate, and drawdown, with a copy trading guide. The verb 'filter' and resource 'lead traders' are specific. However, it lacks differentiation from sibling copy trading tools, and the Chinese text may reduce clarity for non-Chinese agents.
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 okx_get_public_lead_traders. It does not provide context for selection or exclusion.
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 contains '[L:WRITE]' indicating a write operation, but this is already implied by the tool name 'cancel'. No annotations are provided, so the description should disclose side effects, required permissions, rate limits, or idempotency. It fails to do so, leaving behavioral transparency poor.
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 uses non-standard, cryptic notation. It is concise but not clearly structured for an AI agent to parse. The instruction to call agent_catalog is front-loaded but lacks proper formatting.
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 write operation with no output schema, the description is incomplete. It does not explain the result of a successful cancellation, error conditions, or any preconditions beyond calling agent_catalog. The agent lacks information needed to handle the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema provides Chinese descriptions for both parameters (ordId and sprdId). The description does not add additional meaning beyond what the schema already conveys, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses cryptic notation '[L:WRITE] CAT:[策略-价差]' rather than plain language. The tool name 'cancel_spread_order' clearly indicates its function, but the description adds little clarity. It references a category and prerequisite without explicitly stating that it cancels a spread order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite: '→ 请先调用 agent_catalog' (please call agent_catalog first). This provides some guidance but no explicit context on when to use this tool versus alternatives (e.g., other order operations) 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 carries the full burden. It indicates read-only via 'L:READ' but does not disclose any other behavioral traits such as required permissions, rate limits, or side effects. The prerequisite hint is present but insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines) and front-loads the read indicator and category. However, it is terse and lacks explanatory structure. While concise, it sacrifices clarity 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 large set of sibling tools and no output schema, the description is incomplete. It does not explain what the returned data contains, how the prerequisite agent_catalog relates, or what distinguishes this tool from similar ones. A more complete description is needed for a runtime environment without annotations.
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, so the input schema covers 100% of parameter definitions. The description does not need to add parameter info beyond what is already covered. Baseline for zero parameters is 4, and this tool meets that.
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 name clearly indicates 'get co-inviter list', and the description adds 'L:READ' and a category label, but does not elaborate on what the list contains or how it differs from sibling affiliate tools like okx_get_affiliate_invitee_list. The purpose is somewhat clear but not fully specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states to call agent_catalog first, which is a prerequisite guideline. However, it does not provide when to use this tool versus similar affiliate tools (e.g., okx_get_affiliate_invitee_list), nor any context about when it is appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only labels the tool as read-only via '[L:READ]' but omits any other behavioral traits like required permissions, rate limits, or side effects. Inadequate for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short with a single line of tags, which is concise but lacks structured information. It front-loads a read flag and category but does not elaborate on function or output, making it minimally adequate.
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 or output schema, the description should clearly explain what it returns and when to use it. It fails to specify the nature of the copy traders (e.g., all, public, personal) or any return format, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so the description does not need to add parameter meaning. The prerequisite hint is helpful but not parameter-related. Baseline score of 4 is appropriate.
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 indicates a read operation on copy traders via the '[L:READ]' tag, but it does not specify whether these are public or personal copy traders, nor differentiate it from similar sibling tools like okx_get_public_lead_traders. The purpose is vaguely conveyed.
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 only states a prerequisite ('请先调用 agent_catalog') but gives no guidance on when to use this tool versus alternative copy trader tools among siblings. No context on optimal usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description includes [L:READ] hinting at read-only behavior but not formally. It does not disclose return format, side effects, rate limits, or data scope. The dependency on agent_catalog is mentioned 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes non-essential tags like [L:READ] and CAT:[金融] that could be inferred from context. The instruction to call agent_catalog adds necessary but clunky info. It could be more streamlined.
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 should explain what the tool returns and any prerequisites. It only states the basic action and a vague dependency, leaving the agent uncertain about the response format and proper usage sequence.
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, so no parameter description is needed. Baseline of 4 applies as the description does not need to add parameter info. The tool takes no arguments, making this dimension trivially satisfied.
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 tool name indicates 'get lending rate history' and description includes [L:READ] and CAT:[金融], suggesting read-only finance data. However, the instruction '→ 请先调用 agent_catalog' muddles the purpose, implying a prerequisite. It does not clearly distinguish from siblings like okx_get_lending_rate_summary.
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 instruction to call agent_catalog first is a hint but not a clear usage guideline, leaving the agent to infer 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 includes a read-only hint '[L:READ]', which is a positive behavioral disclosure. However, with no annotations and no further details, it fails to describe response behavior, pagination, error handling, or side effects. For a read operation, the description should at least state that it retrieves pending algo orders, which is missing. The read-only hint is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line), which is generally positive, but it sacrifices informativeness for brevity. It front-loads the category and read-only hint, but the structure does not provide a clear task statement. While it avoids verbosity, it could be improved by including a brief purpose without adding length.
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 optional parameters, no output schema, and many related sibling tools, the description is insufficient. It does not explain the scope of 'pending', the types of algo orders included, or how to interpret the results. The prerequisite to 'agent_catalog' is useful but does not compensate for the lack of comprehensive context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, so the schema itself fully documents the parameters. The description adds no further explanation or context for the parameters. According to the rubric, when schema coverage is high (>80%), the baseline score is 3, which is appropriate here.
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 does not explicitly state what the tool does; it only provides a category label '[交易-委托]' and a read-only hint. The tool name 'okx_get_orders_algo_pending' implies it retrieves pending algo orders, but the description lacks a clear verb and resource statement. It is not a tautology but is too vague to fully 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear prerequisite: '请先调用 agent_catalog', which helps the agent understand an ordering dependency. However, it does not provide any guidance on when to use this tool versus siblings like 'okx_get_orders_pending' or 'okx_get_algo_orders', nor does it mention when not to use it. The prerequisite is helpful but insufficient for full differentiation.
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 mentions '[L:READ]' indicating read-only, but lacks details on data returned, side effects, or other behaviors. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but front-loaded with read/category hints. However, the structure is ambiguous and lacks clear English phrasing, reducing clarity for non-Chinese agents.
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, the description fails to explain what the tool returns or how parameters affect results. Sibling tools like 'okx_predictions_search_events' exist but no differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters (sort, limit, status, category) have descriptions in the schema (100% coverage), so the description adds no extra meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only indicates it's a read operation in the 'predictions' category ('[L:READ] CAT:[预测]'), but does not state it lists events. The purpose is vague and requires inference from the function name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call 'agent_catalog' first ('→ 请先调用 agent_catalog'), providing a clear prerequisite. However, no guidance on when to use vs. sibling tools like 'okx_predictions_search_events'.
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 '[L:READ]' tag indicates a read-only operation, which is helpful given no annotations. However, the description does not disclose other behavioral traits (e.g., pagination, rate limits, data freshness). It adds basic transparency 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it lacks structure. The prerequisite instruction is important but is presented cryptically. It could be better organized, but it is not overly 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 absence of an output schema and the complexity of the tool (3 optional parameters, many siblings), the description is insufficient. It does not explain what the response looks like, how filtering works, or how it relates to other prediction tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The tool description adds no additional meaning or context beyond what the schema provides, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'L:READ' and category '预测' provide some context, but it does not explicitly state that this tool lists orders. The meaning is mostly inferred from the tool name 'order_list'. The description is vague and could be clearer.
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 a prerequisite instruction ('请先调用 agent_catalog') but offers no guidance on when to use this tool over siblings such as 'okx_predictions_get_order' or 'okx_predictions_place_order'. No explicit comparisons are made.
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 fully bears the burden of disclosing behavior. It only labels the tool as a write operation ('[L:WRITE]') but does not describe what happens on stop (e.g., immediate cancellation, confirmation, permissions needed), leaving critical behavioral 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 is very concise (one line), but the use of codes like '[L:WRITE]' and 'CAT:[策略-网格]' is cryptic and not well-structured for an AI agent. While short, it sacrifices clarity and could be improved with plain language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a write operation with no output schema, the description should at least explain the tool's purpose and effect. It only offers a prerequisite instruction. Information on required parameters or return values is absent, making it incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning to parameters. The description does not explain the purpose of 'algoId', 'instId', or 'algoOrdType' beyond what the schema provides, earning a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'okx_stop_grid_order' clearly indicates stopping a grid order, but the description uses cryptic prefixes like '[L:WRITE]' and 'CAT:[策略-网格]' without stating the action explicitly. The purpose is vaguely implied rather than clearly stated.
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 instructs to call 'agent_catalog' first, providing a prerequisite. However, it does not compare this tool to siblings like 'okx_close_grid_position' or 'okx_create_grid_order', leaving the agent unsure when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only conveys that it is a write operation ([L:WRITE]), but no other behavioral traits like side effects, permissions, or authorization needs are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with two segments: a label and an instruction. It is concise but not necessarily well-structured, as the most critical information (what the tool does) is 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 the lack of annotations, parameters, and output schema, the description is insufficient for an AI agent to understand how to use the tool correctly. It does not explain the activation process, expected outcomes, or side effects.
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 in the input schema, and schema coverage is trivially 100%. Per guidelines, 0 parameters yields a baseline of 4, and the description adds no parameter-specific information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates it is a write operation for the account category but does not clearly state what 'activating an option' entails. The purpose is vague, relying on the tool name and the instruction to call agent_catalog for 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?
Explicitly instructs to call agent_catalog first, providing a clear prerequisite. However, it does not specify 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only gives a category and a prerequisite, without specifying effects, idempotency, error handling, or return behavior. The '[L:WRITE]' label implies mutation but is not part of the description text.
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 but sacrifices completeness. The prerequisite is front-loaded, but the overall structure is minimal and does not fully serve the agent's needs.
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 that this is a write tool with a complex input (JSON array for batch cancellation) and no output schema, the description fails to mention return values, error scenarios, or any limitations. It is not sufficiently complete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'orders', which includes a description of its JSON format. The tool description adds no additional semantic value beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name 'okx_batch_cancel_orders' clearly indicates its purpose of canceling multiple orders. The description includes '[L:WRITE]' and 'CAT:[交易]' providing context that it is a write operation related to trading, but it does not explicitly state the action in a full sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite '请先调用 agent_catalog', but provides no guidance on when to use this tool versus alternatives like okx_cancel_order, okx_mass_cancel, or okx_cancel_all_after. No 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only includes '[L:READ]' as a custom label, which is not standard. It lacks disclosure of behavioral traits such as rate limits, authentication, data scope, or what happens upon invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is good, but includes non-standard formatting like '[L:READ] CAT:[资金]' and a prerequisite instruction. It could be clearer and more 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 minimal description, the tool lacks important context such as what data is returned (e.g., withdrawal status, dates), pagination behavior, or any date range limitations. For a history tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters (ccy, limit) with descriptions, achieving 100% coverage. The description does not add any additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name clearly indicates retrieving withdrawal history, and the description adds '[L:READ] CAT:[资金]' specifying it's a read operation in the funds category, which helps with basic understanding. However, it does not explicitly distinguish from similar tools like okx_get_deposit_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?
The description only states '→ 请先调用 agent_catalog' (please call agent_catalog first), implying a prerequisite but giving no guidance on when to use this tool versus alternatives. No explicit context for usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only supplies a read hint ('L:READ') and a category, but does not describe side effects, return behavior, access requirements, or error conditions. The lack of detail leaves the agent uncertain about the tool's behavior beyond being 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?
The description is extremely concise, fitting into a single line. It front-loads the read and category tags, followed by the prerequisite. However, it could be more structured with a brief sentence clarifying the tool's action. The brevity is appropriate given the lack of parameters, but some prose would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's name suggests a listing operation, the absence of output schema and behavioral details makes the description incomplete. It does not explain what 'subscriptions' are, what the output format is, or how the prerequisite (agent_catalog) relates. The agent is left without enough context to effectively use the 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 no parameters, so schema_description_coverage is 100%. The description contains no parameter-specific information, which is acceptable since there are none to describe. No additional value is needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lacks a clear statement of what the tool does. While the name 'xlayer_list_subscriptions' suggests listing subscriptions, the description only contains tags '[L:READ]' and 'CAT:[链上]' and a prerequisite directive. It does not explicitly say 'Lists subscriptions' or define the resource being operated on. Other tags like 'L:READ' hint at a read operation but are not definitive.
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 prerequisite ('请先调用 agent_catalog'), but offers no guidance on when to use this tool versus siblings like xlayer_subscribe or xlayer_get_events. There is no explicit context for choosing this tool over alternatives, nor any indication of 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 carries the full burden. It only includes '[L:READ]' to indicate read-only operation, but lacks details on rate limits, authentication requirements, or any side effects. For a non-destructive tool, minimal 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 extremely concise (one line with tags and Chinese) but at the cost of clarity for non-Chinese speaking agents. It could be better structured with a clear English summary. While not verbose, the brevity may hinder 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 three parameters all documented, and a read-only operation, the description combined with the schema provides adequate context for a simple overview tool. However, the lack of an output schema and any indication of response format reduces completeness. Sibling tools with similar complexity also lack output schemas, so this is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description (e.g., 'mode' with enum values explained). The description adds little beyond the schema—only repeating the 'three-in-one' concept. Baseline score of 3 is appropriate as the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides a consolidated view of assets, including fund distribution, earning, and subaccounts, labeled as a 'three-in-one' command center. The 'L:READ' tag indicates read-only purpose. It distinguishes itself from sibling tools like okx_get_balance or okx_get_asset_valuation by being a unified overview, though the use of Chinese and tags may be slightly obscure.
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 does not mention exclusion criteria or scenarios where other tools (e.g., okx_get_balance, okx_get_subaccount_balance) are more appropriate. The agent is left to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It includes a custom label '[L:READ]' suggesting read-only behavior, but does not explain important traits such as data source (real-time/historical), rate limits, or error handling. The description is insufficient for an agent to understand side effects or constraints.
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 line with structured prefix) and front-loads key information (read-only, category, multi-period). It earns a high score for efficiency, though it could be expanded slightly to improve clarity without losing 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?
No output schema exists, yet the description only vaguely mentions 'direction consensus signal' without describing the actual return value (type, structure, fields). Given the tool’s complexity (multi-period calculation generating a report), the description is incomplete for an agent to understand what it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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% (both parameters described). The description mentions multi-period (1H/4H/1D) matching the default bars, but adds no new meaning beyond the schema's own field descriptions. Baseline score of 3 is appropriate when description does not augment understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it computes multi-period (1H/4H/1D) technical indicators and outputs a direction consensus signal. It clearly identifies the verb ('计算' calculate) and resource ('技术指标' technical indicators), and the inclusion of default periods helps distinguish from single-period tools. However, it does not specify the format or structure of the output, 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?
No guidance on when to use this tool versus alternatives. Despite many sibling tools (e.g., agent_market_scan, okx_indicator), the description offers no contextual hints about preferred use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 includes '[L:READ]', indicating a read-only operation, and implies a dependency on agent_catalog. However, it does not disclose other behaviors such as error conditions, pagination, or required authentication beyond the dependency.
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 line) and uses cryptic tags and Chinese text. While concise, it sacrifices clarity for brevity. The structure with tags and arrow is reasonable but could be more readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no parameters, the description should explain what the tool returns (e.g., a list of invitee details) and any relevant context. It only provides a category and a prerequisite, leaving significant gaps about the output format and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description adds no parameter information, but since there are none, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'okx_get_affiliate_invitee_list' is descriptive enough to indicate it retrieves a list of affiliate invitees, but the description adds only cryptic tags ('[L:READ] CAT:[推广]') and a dependency instruction. It does not clearly differentiate from sibling tools like okx_get_affiliate_invitee_detail or okx_get_affiliate_link_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite instruction ('→ 请先调用 agent_catalog'), which is a usage guideline. However, it does not provide any when-to-use or when-not-to-use guidance relative to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the tool is read-only ('[L:READ]') and public ('CAT:[公共]'), but does not disclose any other behavioral traits such as response format, side effects, rate limits, or authentication needs. This is insufficient for a complete understanding.
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 omits a fundamental explanation of the tool's purpose. While it is front-loaded with the read-only indicator and prerequisite, the lack of explicit functionality makes it under-specified. It earns its place but sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description must provide complete context. It mentions the category and a prerequisite but fails to explain what the tool returns or how it fits into the broader system. This is insufficient for an agent to use the tool correctly, especially among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema is empty, covering 100% of the parameters. According to the guidelines, baseline 4 applies. The description does not need to add parameter information, and it does not attempt to, which is appropriate.
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 name implies retrieving announcement types, and '[L:READ]' indicates a read operation. However, the description does not explicitly state what the tool does; it only provides a category and a prerequisite instruction. The purpose is vaguely clear but lacks a specific verb and resource description.
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 instructs users to call 'agent_catalog' first, providing a clear prerequisite. However, it does not explain when to use this tool versus alternatives or provide any context about the tool's role in a workflow. The lineage guidance is partial.
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 hints at being a read operation via '[L:READ]', but discloses no other behavioral traits such as authorization needs, rate limits, or return format. This is minimal disclosure 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but the use of cryptic brackets like '[L:READ]' and 'CAT:[预测]' and the arrow format reduces clarity. It is not well-structured for quick parsing, though it is short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling prediction-related tools, the description lacks completeness. It does not explain what event markets are, what the output looks like, or how this tool differs from similar ones. The prerequisite is helpful but insufficient for a complex toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 the single parameter 'seriesId' (described as '事件系列ID。必填'), so the schema already documents it well. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
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 uses '[L:READ]' and 'CAT:[预测]' to indicate a read operation in the predictions category, but it does not explicitly state that the tool retrieves event markets. The tool name implies the resource, but the description is vague and does not clarify what an 'event market' is. It is better than a tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes '→ 请先调用 agent_catalog', which is an explicit prerequisite: the agent must call 'agent_catalog' first. This is a clear usage guideline. However, it does not differentiate this tool from siblings like 'okx_get_event_events' or 'okx_predictions_get_event_markets', so it could be stronger.
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 marks this as a write operation ('[L:WRITE]'), but with no annotations provided, this is the only behavioral clue. It does not disclose what side effects occur, whether settings are overwritten, authentication requirements, or rate limits. More detail is needed 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 extremely concise (single line). It effectively front-loads the category and prerequisite. However, it may be too minimal, missing context that could be helpful without being verbose. It earns no extra points for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient. It explains neither the overall effect of setting copy settings nor the meaning of parameters beyond what the schema already provides. A more comprehensive description is needed for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a Chinese description in the schema. The tool description itself adds no parameter-level information beyond that. Per guidelines, baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'okx_set_copy_settings' clearly indicates setting copy settings, and the description adds 'CAT:[策略-跟单]' (strategy-following category). It states it's a write operation. However, it does not distinguish this tool from siblings like okx_get_copy_settings, okx_amend_copy_settings, 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 explicitly says '→ 请先调用 agent_catalog' (call agent_catalog first), which provides a prerequisite for usage. However, no guidance on when to use this tool versus alternatives like okx_amend_copy_settings or okx_copy_trader is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only includes a read hint via tag but does not explain what 'status' entails, side effects, or return 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 very concise, with two short sentences. It is front-loaded with key tags and the prerequisite instruction, but the brevity leaves some gaps in clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no params, no output schema, no annotations), the description should at least clarify what the status check returns or its purpose. It falls short by only referencing a prerequisite.
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 zero parameters, the baseline is 4. The description adds no param info, which is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description includes tags suggesting a read operation and a category, but the core purpose 'status' is vague. It does not specify what status information is returned, making it somewhat unclear.
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 instructs the agent to call 'agent_catalog' first, which provides a clear prerequisite. However, it lacks guidance on when to use this tool versus alternatives among the many WebSocket-related 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 alone must disclose behavior. It includes '[L:READ]' which suggests read-only, but this is informal. It does not explain whether the tool returns data or performs actions, nor does it mention side effects or permissions.
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 is front-loaded with a tag and a summary. It could be structured better to separate purpose and modes more clearly.
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 two modes and no output schema, the description fails to explain when to use each mode, prerequisites (e.g., instId for grid_advice), or what the return value looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage), so baseline is 3. The description repeats the mode options but does not add meaning beyond the schema's 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 identifies the tool as a strategy trading center with two distinct modes: active strategy dashboard and grid parameter recommendation. It uses specific verb+resource and distinguishes itself from sibling agent tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies two usage modes but does not explicitly state when to use this tool over other related tools (e.g., agent_quick_trade). No context on prerequisites or alternatives 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?
The '[L:READ]' tag indicates a read-only operation, which is helpful for behavioral transparency given the absence of annotations. However, the description provides no other behavioral details such as side effects, rate limits, or return structure, leaving the agent with minimal information beyond the read hint.
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 with a single line of codes and Chinese text. While it is front-loaded with the read flag, the cryptic style may reduce clarity for AI agents. It is efficient but sacrifices explicitness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description provides a prerequisite (call agent_catalog first) which adds some context. However, it does not describe the return data (e.g., list of signal subscriptions) or complete purpose, leaving gaps in contextual 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?
The tool has no parameters (schema coverage 100%), so the description does not need to add parameter information. The baseline score of 4 is appropriate as no additional semantic value is required.
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 uses codes like '[L:READ]' and 'CAT:[策略-信号]' and suggests calling agent_catalog first, but it does not explicitly state that the tool retrieves signal subscriptions. The purpose is vaguely inferred from the tool name and category, but lacks a clear, direct statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('→ 请先调用 agent_catalog'), which gives some usage guidance. However, it does not specify when to use this tool versus other signal-related tools, nor does it provide any exclusion or alternative 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 fully disclose behavior. The '[L:READ]' hint indicates a read operation, but it lacks details on authentication, side effects, or other behavioral traits. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single line with structured metadata. However, the use of brackets and Chinese may obscure meaning slightly. It is efficient but could be clearer.
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 list tool with no output schema, the description combined with schema is mostly adequate. However, it lacks explanation of return format and why the prerequisite 'agent_catalog' is necessary, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single optional 'enable' parameter, and the description does not add additional meaning beyond the schema. Remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name directly indicates listing subaccounts, and the description adds a '[L:READ]' label and a category, but the Chinese text and bracket format may reduce clarity for some users. It is not a tautology and conveys purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite instruction '请先调用 agent_catalog' (call agent_catalog first), giving some guidance on when to use. However, it does not clarify alternatives or when not to use this tool versus siblings like okx_get_subaccount_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates write permission ([L:WRITE]) and describes batch operations, but does not disclose potential risks (e.g., irreversible cancellation, impact on existing orders) or any rate limiting or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—a single line with clear structure: permission, category, and three operations separated by slashes. No redundancy, but could be slightly more descriptive without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three distinct modes and no output schema, the description should explain what each mode returns or expects. It only lists the actions. For example, what does 'preview' output? No behavioral details for each mode beyond the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameters are already documented. The description adds value by providing Chinese translations for enum values and clarifying that instId is optional ('不填则对所有持仓操作'). No additional format constraints or dependencies are explained 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 lists three distinct modes: preview (查看风控状态), set stop-loss (设止损单), and cancel all (全部撤单). It distinguishes from sibling tools like okx_place_order or okx_cancel_order by focusing on batch stop-loss and global cancellation. However, it lacks a specific verb like 'manage' or 'control' for the overall purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The modes imply usage (e.g., use preview to check status, set_stop_loss to impose loss limits), but there is no explicit guidance on when to use this tool versus alternatives like okx_place_algo_order or okx_cancel_order. No exclusion criteria or prerequisites are 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?
No annotations are provided, so the description must convey behavioral traits. The '[L:READ]' tag indicates a read-only operation, but the description does not elaborate on rate limits, authentication, or side effects. It adds some value beyond the schema but remains minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the read hint and category tag. It includes a prerequisite instruction in a single line. While cryptic, it is concise and 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 no output schema, and the description does not explain what the tool returns or provide context on the scope of the data (e.g., date range, asset types). The prerequisite hint is useful, but overall the description is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'limit' parameter (integer, min 1, max 100, default 100). The description adds no additional semantic meaning to this parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 is for retrieving asset bills history, and the '[L:READ]' tag specifies it is a read operation. However, it does not differentiate itself from the many sibling tools or explain what exactly 'asset bills history' entails.
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 '→ 请先调用 agent_catalog' (call agent_catalog first), which is a clear prerequisite for using this tool. It does not mention when not to use it or provide alternatives, but the prerequisite guidance is valuable.
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; description includes a read hint '[L:READ]' but does not disclose behavioral traits like permissions, rate limits, or side effects. It adds context about combining multiple data sources but lacks depth on what happens during execution or output 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?
Description is very concise, using a single line with structured formatting. It front-loads the core purpose and modes. However, abbreviations (PCR, CAT, L:READ) and brackets may be cryptic for some agents, slightly reducing 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?
No output schema; description mentions outputs like 'direction score' and 'funding arbitrage opportunities' but does not detail their format or structure. For a tool with 5 parameters and two modes, the description is adequate but could be more complete regarding return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description groups parameters by mode (sentiment vs funding) but does not add significant extra meaning beyond schema descriptions. The two modes are mentioned, but parameter-specific guidance is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 a specific verb-resource combination: market sentiment comprehensive analysis using multiple indicators (long-short ratio, PCR, funding rate, whale sentiment) to produce a direction score or scan funding rate arbitrage. It distinguishes itself from sibling tools like agent_market_scan and agent_option_scanner by focusing on sentiment indicators and funding arbitrage.
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 sentiment analysis or funding arbitrage scanning but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The two modes (sentiment and funding) are clear, but no exclusions or recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions a read operation and scanning, lacking details on authentication, side effects, or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with tags, front-loading the read type and category. 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 parameters, no output schema, and a straightforward purpose, the description adequately explains what the tool does. It could mention expected output or behavior, but it's sufficient for a simple scanning 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?
There are zero parameters, so baseline 4 applies. The description adds no parameter information, but none 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 it scans prediction market events for risk-free arbitrage opportunities where YES+NO spread < 1.0, with a specific verb and resource. It distinguishes itself from sibling tools like outcomes_check_arbitrage.
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 outcomes_check_arbitrage or other prediction tools. Usage is implied but not clarified.
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 responsibility. It indicates a read operation with cross-session persistence, but does not elaborate on error behavior, performance, or authorization needs. The basic safety profile (read-only) is clear, but additional behavioral details 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line with front-loaded tags that categorize the tool. It is efficient and contains no filler. While the use of Chinese and tags may introduce slight noise for an English-only agent, it remains concise and direct.
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 low complexity with one optional parameter and no output schema. The description covers the essential behavior, and the schema details the parameter. However, it does not describe the return format (e.g., JSON object), which would aid completeness. Overall adequate for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% and includes a clear description of the 'key' parameter: 'preference key name, returns all if not filled'. The tool description does not add any additional semantics beyond what the schema already provides. Baseline 3 is appropriate given 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 reads persistent preferences of the agent that are retained across sessions. The verb '读取' (read) and the resource 'Agent持久化偏好' are specific. It is distinguishable from the sibling tool 'agent_set_preference' which would be a write operation.
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 (read preferences) but provides no explicit guidance on when to use this tool versus alternatives like agent_set_preference. There is no mention of when not to use it or contextual conditions. The agent must infer from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The [L:READ] label indicates a read operation, but no annotations are provided, so the description carries full burden. It discloses the data categories returned but omits any behavioral traits like rate limits, authentication needs, or side effects. Given the read-only nature, this is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with useful labels ([L:READ], category). Every sentence provides essential information. The mixed Chinese-English is acceptable for the domain but slightly reduces universal 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 aggregates multiple option metrics and has no output schema, the description accurately sets expectations for the type of data returned (summary, OI distribution, PCR, block volume). It is complete enough for an agent to understand the tool's scope, though exact output structure is unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (uly) described in the schema. The tool description does not add any parameter-level detail beyond the schema. Baseline 3 is appropriate as the schema already documents the parameter sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'panoramic scan' of options, providing summary, OI expiry/strike distribution, PCR, and block trading volume. This specific verb-resource combination distinguishes it from sibling tools that cover individual metrics like okx_get_option_oi_expiry or okx_get_option_taker_block_volume.
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 use for a comprehensive options overview, contrasting with sibling tools that focus on single metrics. However, it lacks explicit guidance on when not to use this tool or mention of alternative tools for more granular 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?
No annotations provided. The description compensates by declaring read-only (READ) and public (PUBLIC), plus small return size (~3KB). This discloses the safety profile and impact. It doesn't mention rate limits, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with sections (purpose, scenarios, keywords, parameters, auth, risk, related tools). It front-loads the purpose and uses clear headings. Some redundancy (keyword lines) could be trimmed, but structure aids scanning.
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 return content (top N sorted), data volume, and links to downstream tools. It also specifies auth and risk. It does not detail exact output format, but for a scanning tool this is adequate. The workflow context adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. The tool description repeats parameter info almost verbatim (defaults, enum meanings), adding no new semantic value. Baseline 3 is appropriate; the description does not enhance 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 it scans market anomalies (gainers, losers, volume surges, funding rate anomalies). It differentiates from siblings like okx_get_ticker (single ticker) and okx_quick_market (deep analysis) by being a one-click scan. Use cases are concrete: '今天有什么机会', detecting surges, arbitrage targets.
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 lists scenarios: 'Agent回答今天有什么机会', finding sudden surges, funding rate arbitrage. It also provides a workflow chain: scan → okx_quick_market → agent_quick_trade, guiding when to use this versus deeper analysis tools. However, it 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?
No annotations are provided, so the description carries full weight. It discloses that the tool is read-only ('RISK: READ — 只读'), requires no authentication (PUBLIC), accesses a local database, and returns small payloads (~2KB). It does not mention caching or behavior for invalid input, but the risk profile is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers, keywords, and parameter list. It is front-loaded with the core function. Although longer than necessary, every sentence adds value. Minor redundancy with schema description but acceptable.
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 output schema, no annotations), the description covers purpose, usage, auth, risk, return size, and relation to sibling. It lacks details on output format or error handling, but the return size hint compensates somewhat. Reasonably complete for a read-only query.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 is 3. The description's parameter section repeats the schema's descriptions in a structured format but does not add significant new semantic meaning. It clarifies the mode enum values slightly, but the schema already provides adequate 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 a code knowledge graph for call chains, symbol search, file listing, and impact analysis. Example scenarios are provided, distinguishing it from sibling tools that focus on OKX trading or general agents.
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 concrete scenarios for when to use the tool, e.g., when the agent needs to answer questions like 'toResult被哪些工具调用'. It also lists keywords and a related tool (codegraph_status), though it does not explicitly state when not to use or compare to alternatives. The sibling set is dominated by OKX APIs, so the purpose is already 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 provided, the description fully discloses behavioral traits: declares [L:READ] and '风险：READ — 只写日志，Agent 可随时调用' (risk: READ - only logs, Agent can call anytime), indicating no side effects. Also specifies '鉴权：PUBLIC — 无需 API Key' and return size '微小 ~200B'. 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?
Description is well-structured with sections (功能, 场景, 关键词, 参数, 鉴权, 风险, 返回量, 关联), but it is somewhat verbose. Every section serves a purpose, but could be more concise. Front-loads key info with [L:READ] and CAT, which helps.
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 has 5 parameters (all required), no enums, no output schema, and no annotations, the description covers function, usage scenarios, parameter descriptions, authentication, risk, return size, and follow-up process. It is fully complete for the agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds brief explanations for each parameter (e.g., '一句话标题', '你做了什么操作'), which adds some meaning beyond schema labels. However, it does not provide detailed formatting 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?
Description clearly states the tool's purpose: submitting feedback about MCP tool usage pain points. It specifies the verb '提交' (submit) and resource '使用反馈' (usage feedback). It distinguishes itself from sibling tools by explicitly listing scenarios when to use it, such as multi-step issues, parameter trial errors, or inability to find 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?
Description provides explicit scenarios for when to use the tool: when encountering tedious multi-step operations, parameter trial error, unknown call order, can't find tools, or need to supplement with manual calculations. It lacks explicit 'when not to use' or alternatives, but the positive conditions are clear and specific.
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 read-only behavior ('只读查询'), authentication requirements (API Key with read-only), and that no orders are created. It also mentions return size (~1KB). Lacks explicit error conditions or rate limits, but given the read-only nature, 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?
Well-structured with sections (功能, 场景, 参数, etc.) and uses front-loading with the [L:READ] tag. However, it is somewhat verbose with repeated '必填' and a keyword list that may not be necessary. Could be tightened without losing 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?
Covers purpose, usage, params, auth, risk, and returns size. However, no output schema is provided, and the description does not specify the return format (e.g., success/failure indicators, error messages). For a preflight check tool, this is a notable gap as the agent needs to interpret the response to proceed.
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 100%, baseline 3. The description adds significant meaning beyond the schema: it gives examples (instId: BTC-USDT-SWAP), explains auto-conversion (sz), conditional checks (px limit, side max open, ordType limit range), and enum meanings (tdMode: cash/cross/isolated). This enrichment fully compensates for any schema brevity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 a preflight check before placing an order, checking max open quantity, price limits, contract conversion, and current price. It provides keywords and explicitly names the workflow step (precheck -> place order -> confirm). This distinguishes it from other tools like okx_place_order and okx_order_precheck.
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 'Agent下单前必调' (must call before placing order) and lists scenarios. It explains when parameters are checked (e.g., side for max open, px/ordType for limit price). However, it does not differentiate from the sibling tool okx_order_precheck, which appears to serve a similar 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 provided, the description clearly declares read-only status, authentication requirements (API key), and return size (~2KB). This covers key behavioral aspects beyond the schema, though it could mention whether data is real-time or historical.
Agents need to know what a tool does to the world before calling it. Descriptions 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 headers (function, scenario, keywords, parameters, authentication, risk, return size, related tools), front-loading the purpose. Every section 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 simple tool with one parameter, the description covers input, usage, safety, and relationships. It lacks return format details, but the return size hint partially compensates. Overall, it is sufficiently complete given the tool's simplicity and lack of 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 describes the 'days' parameter with constraints and a short description. The description adds context that the default is 7 days and that it applies to realized PnL, enhancing understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 generates a PnL report including current floating PnL and realized PnL for a configurable number of days (default 7). The resource and verb are explicit, and it is distinct from sibling tools like agent_risk_overview which addresses broader risk.
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 concrete scenarios (e.g., answering 'how much I earned today', daily reporting) and a workflow linking related tools. However, it does not explicitly state when not to use this tool or provide direct alternatives, though the workflow implies complementary 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 provided; description discloses it is a WRITE operation (real order), requires API key with trade permission, and returns ~1KB data. Does not detail side effects beyond placing order, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with headings and bullet points, front-loading function and scenario. Some redundancy but overall clear 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?
Covers function, scenario, parameters, auth, risk, return size, and related tools. Without output schema, explains return includes precheck results, order confirmation, and risk reminders. Complete for a multi-step 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 100% so baseline 3. Description adds Chinese translations, notes optional px, default ordType, and explains parameters in context of quick trade, adding 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?
Description clearly states it performs a one-step trade with automatic balance, max quantity, price limit checks, and order placement, returning structured confirmation. Distinguishes itself from separate tools like okx_place_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?
Explicitly says to call when user says 'buy 0.1 BTC' and that no need to call separate tools. Lacks explicit when-not conditions, 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 provided, the description carries full burden. It discloses authentication requirements (API key, read-only), risk type (READ), and expected response size (∼2KB structured summary). This provides good transparency beyond a simple 'read-only' hint, though it lacks details on potential error states 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 labeled sections (功能, 场景, 关键词, etc.) and each part adds value. It is slightly verbose but efficient, conveying all necessary information without redundancy. The format is easy to scan for key details.
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 is highly complete. It covers purpose, usage scenarios, behavioral traits (auth, read-only, response size), and even provides a workflow linking to downstream tools. This ensures an agent can correctly select and invoke the tool 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 input schema has zero parameters, and the description explicitly notes '参数：无'. Since there are no parameters to document, the description adds no additional semantic burden. The baseline for no parameters is 4, and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as a one-click risk dashboard covering position risk ranking, total margin rate, liquidation warnings, and funding rate expiry reminders. It specifies the trigger scenario ('Agent answering 'how risky am I now?') and uses distinct keywords, differentiating it from sibling tools like okx_get_account_position_risk or okx_get_risk_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?
The description provides explicit usage scenarios (risk check, health inspection, liquidation alert) and includes a workflow linking to other tools (agent_quick_trade, agent_pnl_report). However, it does not explicitly state when not to use it or mention alternative tools, so no exclusion guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses read-only nature, required API key, small return size (~3KB), and risk level. It could add more on speed or cost, but covers the essentials.
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 keywords, but slightly verbose with tags and repetition. It is front-loaded with purpose and usage, earning its 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?
Despite no output schema or annotations, the description fully covers purpose, usage, auth, risk, return size, and workflow. It is self-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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. The description adds value by explaining what data the tool returns (balance, positions, etc.), which is 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 it provides a full account overview (balance, positions, config, valuation) and replaces 4 tools. It distinguishes itself from siblings by being a one-stop holistic view vs. detailed tools like okx_get_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 specifies use cases: 'first-time account overview', answering 'what's my account status', daily asset check. It also provides workflow context linking to deeper tools. However, it lacks explicit when-not-to-use or exclusion of 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?
Since no annotations are provided, the description carries full burden. It explicitly states 'READ' and '只读查询' (read-only query), and notes return size (~2KB, 5-depth, not full orderbook). This is adequate for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description uses structured headers and lists, making it easy to scan. It is slightly verbose but every section adds value. Could be more concise but still good.
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 market snapshot with one parameter, the description covers functionality, usage scenario, auth, risk, return size, and related tools. It is fully complete 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 coverage is 100% with a clear description for instId. The description repeats the parameter info but adds no new semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: returning a structured summary of market data (ticker, 5-level depth, funding rate, product specs) for a given product. It distinguishes from siblings by combining multiple data points into one call.
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 a concrete use case ('now BTC what's the situation') and a tool chain: this tool for quick overview, then okx_get_candles for deeper K-line, okx_get_orderbook for full depth, okx_place_order for trading. It also mentions the tool is read-only and public.
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 fully bears the burden. It discloses authentication (PUBLIC), risk (READ, local file write, no fund risk), and return size (~200B). This provides necessary behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: function, scenario, keywords, parameters, auth, risk, return size, relationship, and common keys. Every section adds value without verbosity. It is 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 the tool's simplicity (2 params, no output schema), the description covers all necessary aspects: purpose, usage scenario, parameter guidance, risk, auth, and relationships to sibling tools. It provides a complete and self-contained 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?
The input schema covers both parameters with descriptions. The description adds value by listing common key names and their meanings (e.g., default_instId, risk_level), which helps the agent form correct invocations 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: setting persistent preferences for the agent, with cross-session retention. It provides a concrete scenario (user says 'future default trading pair') and lists keywords, making it distinct from sibling tools like agent_get_preference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a scenario and keywords for when to use, and explicitly links to agent_get_preference for reading. It provides common key names as guidance. While no explicit 'when not to use' is given, the context is sufficient for 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?
With no annotations provided, the description fully discloses behavioral traits: authentication ('PUBLIC — local DB read'), risk ('READ — read-only'), and return size ('~1KB'). This goes beyond the schema and provides essential 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 structured with tags and sections, each adding value. It is concise given the information packed, though the format is slightly verbose with multiple lines. Still well-organized.
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 explains what the tool returns and its usage context. It provides all necessary information for an agent to decide when and how to use this 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 tool has zero parameters, so there is nothing to add. The description explicitly states 'No parameters', which is clear. Baseline score for no params 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 checks the status of the code knowledge graph and lists the exact information it returns (node count, edge count, covered files, most called functions). It distinguishes itself from the sibling 'codegraph_query' by mentioning the use case sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Agent first connection to confirm graph readiness'. It also implies a sequence with 'codegraph_query'. However, it does not explicitly mention when not to use it or alternatives, but the context makes it 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?
Despite no annotations, the description discloses key behaviors: it is read-only (READ), public authentication, small response (~2KB), and returns parameter hints, auth requirements, and workflow. This is sufficient for an agent to understand the tool's impact 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 well-organized with clear headings, front-loaded with a summary, and each section provides necessary information without redundancy. Every sentence adds value, making it easy for an agent 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 the simple input (one parameter) and no output schema, the description covers all necessary aspects: purpose, usage scenario, parameters, authentication, risk, response size, and workflow. It is complete for an agent to use this tool effectively.
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 provides a description and possible values for the domain parameter. The tool description adds context by listing values in a structured format and linking the parameter to the catalog workflow. Although there is slight inconsistency in values, it adds meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: viewing a detailed tool list for a specific business domain, including parameter hints, authentication requirements, and recommended call order. This distinguishes it from sibling tools that provide actual data or execute 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?
The description explicitly specifies the usage context: after using agent_catalog to select a domain, call this tool to get detailed information. It also outlines the intended workflow: agent_catalog -> this tool -> direct target tool call, providing clear guidance on when to use it 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 fully covers behavior: it is read-only, does not create real orders, requires API key, returns small data (~1KB), and outlines the simulation flow. It ensures the agent knows it is safe 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?
Well-structured with clear sections (function, scenario, keywords, parameters, auth, risk, return size, link). Each 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.
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 lists returned values (estimated price, slippage, fee, capital) and covers auth and risk. It is complete for a simulation tool, providing all necessary context for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context for each parameter (e.g., side with buy/sell translations, px as optional for limit orders). It repeats some schema info but enhances understanding with usage 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 simulates an order without creating a real one, returning estimated values such as price, slippage, fees, and capital usage. It distinguishes itself from real order tools like agent_quick_trade, and mentions specific outputs.
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 the use case: when the agent answers 'what if I buy 0.1 BTC now' to let users understand costs without risk. It also links to the next step (agent_quick_trade for real ordering), providing clear 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.
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: it is read-only ('[L:READ]', '风险：READ'), public authentication ('鉴权：PUBLIC — 纯索引，不查任何 API'), takes no parameters, returns a small (~5KB) structured index of 12 domains. There are no contradictions between description and any implicit 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 well-structured with clear tags ([L:READ], CAT, etc.), a function overview, usage scenarios, keywords, parameter note, authentication, risk, and return size. Despite being in Chinese, each section is concise and adds unique value. The information is front-loaded with the most critical details (read-only, public, entry-point tool). No extraneous content.
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 (no parameters, no output schema), the description provides all necessary context: it explains the tool's role in the navigation workflow, the structure of the returned map (12 domains grouped by intent), the small response size, and the relationship to agent_catalog_detail. An agent can fully understand when to use this tool and what to expect 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?
The tool has no parameters, and the input schema is empty (100% coverage). The description explicitly states '参数：无', confirming no input is required. While the schema alone already conveys this, the description adds clarity by reinforcing the absence of parameters and explaining that no user input is needed. Since the schema coverage is complete, a baseline of 3 applies, but the explicit confirmation and additional context (e.g., '纯索引') justify a score 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 clearly states the tool's purpose as a global tool navigation ('全局工具导航') and designates it as the first tool to call upon initial connection. It specifies that it returns a tool map grouped by user intent, distinguishing it from sibling tools like agent_catalog_detail, which handles domain-specific details. The verb-resource pairing is explicit 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 usage scenarios: 'Agent 首次连接 hvip MCP 后第一个应调用的工具' (first tool on first connection) and '不确定该用什么工具、想了解 hvip 能做什么' (when unsure what tool to use or wanting to understand capabilities). It also outlines a workflow: start here, then use agent_catalog_detail for domain details, then directly call target tools. This gives clear when-to-use and 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.

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:

[![hvip-mcp MCP server](https://glama.ai/mcp/servers/okx-wallet-H/hvip-mcp/badges/card.svg)](https://glama.ai/mcp/servers/okx-wallet-H/hvip-mcp)

Score Badge

Copy to your README.md:

[![hvip-mcp MCP server](https://glama.ai/mcp/servers/okx-wallet-H/hvip-mcp/badges/score.svg)](https://glama.ai/mcp/servers/okx-wallet-H/hvip-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/okx-wallet-H/hvip-mcp'

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