Server Quality Checklist

Tool Scores

• scan_spreadsC
  2.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It merely says 'scan', which implies a read operation, but does not disclose return format, sorting, rate limits, or how parameters like minSpread and minVolume affect behavior. No side effects or special traits 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with two sentences that front-load the core action and a use case. It contains no unnecessary words, and every sentence serves a purpose—although the conciseness sacrifices substantive detail, it is well-structured for what it includes.

  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 five configurable parameters and no output schema, the description is severely incomplete. It does not explain what the returned data looks like, how parameters interact, or any default behavior. This is inadequate for an agent to select and invoke the tool correctly without additional assumptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, and the description provides no explanation of the five parameters (limit, maxPairs, minSpread, minVolume, quoteAsset). This leaves the agent to infer meaning from parameter names alone, which is insufficient for correct invocation, especially for parameters like minSpread with a default of 0.1.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool scans for wide bid-ask spreads across trading pairs, using a specific verb and resource. It also provides context via 'useful for market-making opportunities', but does not explicitly differentiate from sibling tools like scan_best_opportunities or get_spread, preventing a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  While it mentions market-making opportunities, it does not provide explicit guidance on when to prefer this tool over alternatives such as get_spread or scan_best_opportunities. There are no exclusion criteria or clear context beyond the vague use case, leaving the agent without adequate usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_all_pairsC
  2.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description bears the full burden of disclosing behavior. It mentions the output includes volume and spread data, but does not state whether results are sorted, paginated, filtered by liquidity, or what happens for pairs with missing data. No details on 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.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence, which is concise, but it omits critical context such as parameter semantics and usage scenarios. It is under-specified rather than appropriately concise, earning a middle score because the sentence does effectively communicate 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 lack of annotations, output schema, and incomplete parameter explanations, the description is insufficient for an agent to confidently invoke the tool. With two optional parameters and zero explanation, the agent cannot know what values to pass or what the response will look like. The minimal context provided is not enough for correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description makes no attempt to explain the parameters. minVolume and quoteAsset are introduced only in the schema with type information, but the agent cannot infer their purpose or how they affect the returned pairs. The description adds no value beyond the schema for parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb 'Get', a clear resource 'all trading pairs', and explicitly mentions the data fields 'volume and spread data'. This distinguishes it from siblings like get_spread (single pair spread) and get_ticker (single pair 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?

  No guidance is provided on when to use this tool versus alternatives. The name and description imply it lists all pairs, but there is no explicit mention of when to prefer it over get_spread, get_ticker, or scan_spreads, nor any exclusions or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_leverageC
  2.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get current leverage' without confirming whether this is a read-only operation, what permissions are required, or what side effects might occur. It does not mention anything about positionSide or edge cases like unsupported symbols.

  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, clear sentence that gets straight to the point. It is front-loaded with the verb and avoids extraneous wording. While it is brief, that brevity is appropriate for the tool's simplicity, though it sacrifices necessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has two parameters and no output schema, the description is under-specified. It does not convey what the response will look like, how positionSide affects the result, or what symbol formats are valid. The absence of annotations and output schema makes this basic sentence insufficient for a reliable AI agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has two parameters (symbol, positionSide) with 0% description coverage. The description mentions neither parameter, failing to explain the required symbol format (e.g., slash-separated) or the positionSide enum values and its default of 'short'. This leaves the agent without essential context for invoking the tool correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description explicitly states the action ('Get') and the resource ('current leverage') for a specific context ('perpetual futures symbol'), which clearly distinguishes it from the sibling tool 'set_leverage' that performs the opposite action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives such as 'set_leverage'. There is no mention of scenarios, exclusions, or connections to other tools. The agent is left to infer from the tool name alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_spreadC
  2.8/5.0
  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 says 'Get bid-ask spread' implying a read operation, but does not specify data source, calculation method, units, or potential side effects. 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, direct sentence that immediately conveys the core function. It is free of redundancy and perfectly 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 output schema and no annotations, the description is incomplete. It does not mention what the response contains, edge cases, or any operational context. An agent would not know what to expect from the call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description refers to 'trading pair' which clarifies that the 'symbol' parameter is a pair, but it does not explain the format beyond the schema's pattern. With 0% schema_description_coverage, the description should compensate more, but it adds little.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves the bid-ask spread for a trading pair, with the verb 'Get' and resource 'bid-ask spread' specific. The singular 'a trading pair' implies a single pair, helping distinguish it from sibling 'scan_spreads', though it doesn't explicitly contrast them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like get_ticker or scan_spreads. There are no exclusions, prerequisites, or context hints about preferred usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_indicatorC
  2.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries full burden for behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not disclose return format, execution details, or potential errors. It is minimally adequate for a non-destructive tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence, front-loaded with the action verb 'Get' and includes the key resource and supported indicator types. Every word contributes to the core message without unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 4 parameters, no output schema, and no parameter documentation in the schema. The description is far too terse to cover these gaps: it omits how 'period' and 'timeframe' affect the result, and gives no indication of return structure. This is a clear gap for a tool with this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate by explaining parameters. It merely lists indicator enum values (already present in the schema) and says nothing about 'period' or 'timeframe'. This adds no semantic value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool retrieves a specific technical indicator value and lists the supported indicators, which differentiates it from sibling tools like get_ticker or get_ohlcv. However, it does not explicitly contrast with analyze_symbol_ta, so it stops short of a perfect score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention when it is appropriate to call get_indicator instead of get_ohlcv or analyze_symbol_ta, nor does it state any prerequisites or exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_ohlcvC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description bears full responsibility for disclosing behavior, but it only states what the tool returns. It omits details such as default limit, maximum limit, pagination behavior, handling of the 'since' parameter, or any rate limit constraints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence followed by a compact list of timeframes. It is appropriately sized and front-loaded with the core purpose, 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?

  Despite being a simple read tool, the absence of annotations and output schema leaves significant gaps: no return format, no pagination or limit details, no clarification of parameter semantics, and no situational guidance. The description is minimal but not complete enough for unassisted use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not compensate. It merely repeats the timeframe enum already present in the schema, and provides no explanation of 'symbol' format, 'limit' behavior, or 'since' semantics, so it adds no value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Get historical candlestick data (OHLCV)' with a specific verb and resource, and enumerates supported timeframes, which distinguishes it from siblings like get_ticker or get_spread.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool instead of alternatives. There is no mention of scenarios, exclusions, or comparisons to other data retrieval tools, leaving the usage context entirely unclear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_orderbookC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Get,' implying a read operation, but does not specify whether data is live or snapshotted, the response format, or any limitations. For a simple getter, this is minimal 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that is front-loaded with the action verb. Every word serves a clear purpose, though it could be slightly more informative without becoming verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of annotations and output schema, the description is incomplete. It does not describe the return structure (e.g., bids/asks), the significance of 'depth,' or any edge-case behavior. The agent is left without enough context to anticipate the response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description adds little beyond the schema. It implicitly refers to the 'symbol' parameter ('trading pair') but does not explain the 'limit' parameter or the symbol pattern. The description fails to compensate for the lack of parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Get order book depth for a trading pair.' It uses a specific verb ('Get') and resource ('order book depth') with a clear scope ('for a trading pair'), which distinguishes it from sibling tools like get_ticker or get_spread.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or comparisons to sibling market data tools, so an agent receives no decision support.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scan_best_opportunitiesC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool returns 'best trading opportunities' but does not explain how 'best' is determined, what filtering or ranking logic applies, whether the operation is read-only, or any side effects. This leaves significant behavioral aspects undisclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise at two sentences, but the second sentence ('Returns the best trading opportunities') largely restates the implication of the first sentence, adding minimal value. It is not verbose, but the redundancy prevents a perfect 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?

  For a tool with eight parameters, no output schema, and no annotations, the description is severely under-specified. It does not explain result ordering, output format, how filters interact, or the meaning of 'best' opportunities. The description is a high-level summary rather than operational documentation, leaving an 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.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description mentions the combination of spread, volume, and TA signals, which aligns with several parameters (minSpread, minVolume, signalType, minTAConfidence), but does not explicitly name or explain any of the eight parameters. With 0% schema description coverage, the description should compensate, but it only provides a high-level hint and leaves parameter semantics entirely to 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 identifies the tool as a comprehensive market scan combining spread, volume, and TA signals. This distinguishes it from sibling tools like scan_spreads or find_ta_signals which focus on individual signal types, making its purpose transparent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives no explicit guidance on when to use this tool versus alternatives such as scan_spreads, analyze_symbol_ta, or find_ta_signals. It only implies broad usage via 'comprehensive market scan' but lacks any context about specific scenarios, exclusions, or prerequisites.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• find_ta_signalsB
  3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It discloses that results are 'ranked by confidence' but omits important behavioral details such as whether it is read-only, what 'confidence' means, how many pairs are scanned, or what the return structure looks like. This 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description consists of two short sentences that directly state the action and output. It is front-loaded and contains no fluff. Each sentence earns its place. It is appropriately concise, though it sacrifices detail for brevity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is complex with 7 optional parameters, no output schema, and no annotations. The description is too sparse to guide an agent effectively: it does not explain parameter meanings, the definition of 'confidence', the output format, or the default behavior when no parameters are provided. Significant details are missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 7 parameters with 0% description coverage, meaning no property descriptions. The tool description does not mention any parameter (limit, maxPairs, minVolume, timeframe, quoteAsset, signalType, minConfidence) and therefore adds no semantics beyond the raw schema. The agent cannot infer what each parameter controls.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 scans trading pairs for technical analysis signals and returns buy/sell opportunities ranked by confidence. The verb 'scan' and resource 'trading pairs' effectively distinguish it from single-symbol analysis tools like get_indicator or get_ohlcv.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage: when you want a broad market scan for TA opportunities. However, it does not explicitly mention alternatives or when not to use it, such as when analyzing a specific symbol (analyze_symbol_ta) or scanning spreads (scan_spreads). The context is clear but no exclusions are stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cancel_all_ordersB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden. It states the action and scope but omits details about side effects, irreversibility, permissions, or any confirmation/return behavior. For a destructive bulk operation, this is a significant gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence of about 10 words that directly states the action and optional filter. It is concise with zero wasted words, earning high marks for efficiency.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple with one optional parameter and no output schema or annotations. The description adequately covers the core function and parameter meaning, but it lacks any mention of return values, safety warnings, or why one might prefer this over 'cancel_order'. It is minimally viable but not rich in context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides only a regex pattern for the optional 'symbol' parameter with no description. The description adds meaningful context by explaining that the symbol is optional and filters which open orders are cancelled, compensating for the 0% schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Cancel' and resource 'all open orders', with an optional symbol filter. It distinguishes from the sibling 'cancel_order' by mentioning 'all', but does not explicitly contrast the two.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus the sibling 'cancel_order' or other alternatives. There is no mention of prerequisites, exclusions, or scenarios where this bulk cancellation might be inappropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• cancel_orderB
  3.2/5.0
  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 implies only open orders can be cancelled but doesn't state what happens if the order is already closed/not found, whether cancellation is immediate, or any side effects. Very limited behavioral detail.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single concise sentence with no unnecessary words. It efficiently communicates the core purpose with zero waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (2 parameters, no output schema), but the description lacks context about return behavior, error handling, or the role of 'symbol'. It's minimally viable but leaves gaps that could matter 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 description coverage is 0%, so the description must compensate. It clarifies 'orderId' as the order identifier, but completely omits 'symbol', which is a required parameter. Partial compensation only.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('cancel') and the resource ('an open order') with a specific identifier ('order ID'). This unambiguously distinguishes it from siblings like 'cancel_all_orders' and '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?

  The description provides no guidance on when to use this tool versus alternatives, nor any context about prerequisites or implications. It simply states the action without explaining when it's appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_leverageB
  3.2/5.0
  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 discloses support for isolated/cross margin but omits behavioral traits such as persistence across sessions, effects on existing positions, required permissions, or error conditions. As a mutation tool, these details are important.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with two short sentences that front-load the action and provide a clarifying example. Every word adds value, and there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations and no output schema, the description should provide more context about return values, prerequisites, and side effects. It does not mention what happens after setting leverage, how positionSide interacts, or potential errors. The description is a minimal viable but leaves 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?

  With 0% schema coverage, the description partially compensates by illustrating the symbol format (BTC/USDT:USDT) and leverage value (10x), and explicitly mentions isolated/cross margin, which maps to marginType. However, positionSide is not explained, so the parameter semantics are incomplete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Set leverage') and resource ('perpetual futures trading'), with an example that clarifies the symbol format and leverage values. It clearly distinguishes from sibling tools like get_leverage (read vs. write) and place_order (order placement vs. leverage configuration).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 when-to-use or when-not-to-use guidance is provided. The description implies it is for setting leverage before trading but does not mention alternatives or preconditions. Sibling tools like get_leverage or place_order are not referenced.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_open_ordersB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the core behavior (returning all open orders, optionally filtered by symbol) but does not mention response format, pagination, or any side effects. The read-only nature is implied but not explicitly stated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence with two concise clauses, providing essential information without extraneous detail. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimally sufficient for a simple read tool, but the absence of an output schema or any mention of return structure leaves the agent uncertain about the result format. It covers the basic operation but lacks depth expected for a tool with no 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?

  The description explains that the only parameter, 'symbol', is used for optional filtering and that omitting it returns all open orders. This adds meaning beyond the schema's bare pattern, compensating for zero schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves open orders with an optional symbol filter. It is specific and unambiguous, but it does not explicitly differentiate from sibling tools like get_positions or get_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?

  No guidance is provided on when to use this tool versus alternatives. There is no mention of preferred scenarios, exclusions, or prerequisites, leaving the agent to infer usage from the description alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• analyze_symbol_taA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly communicates that the tool performs calculations and returns a recommendation, which implies a read-only analytical operation. However, it does not explicitly state that the operation is non-mutating or mention any limitations (e.g., rate limits, data freshness, or errors). The indicators and output description provide substantive 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 two sentences, efficiently front-loaded with the main action. Every word contributes meaning, with no redundancy or filler. It is concise while covering the tool's core purpose and output.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex analysis tool with no output schema, no annotations, and undocumented parameters. The description gives only a high-level overview, omitting details like the confidence score range, how limit and timeframe influence the recommendation, and any error behavior or prerequisites. For an agent to use it correctly and trust the output, more context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 0%, so the description must compensate, but it only mentions 'symbol' generically. It does not explain the 'limit' or 'timeframe' parameters, their defaults, or how they affect the analysis. This leaves two of three parameters semantically undefined for the agent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool runs a 'full technical analysis' on a symbol, enumerates the specific indicators used (RSI, MACD, EMA, Bollinger Bands, Stochastic), and specifies the output (buy/sell/hold recommendation with confidence score). This is a specific verb+resource+output definition that distinguishes it from sibling tools like get_indicator, which likely provides a single indicator value.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies this is for comprehensive analysis ('full technical analysis') but does not explicitly state when to use it over alternatives like get_indicator or find_ta_signals. It provides no exclusions, prerequisites, or contextual conditions. Usage guidance is only implicit, not explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• place_orderA
  3.7/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of disclosing behavior. It does add valuable context: amounts and prices must be strings, and orders are simulated in demo mode. However, it omits details about live order execution, side effects, or response behavior, so it is adequate but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences, immediately states the core action, and provides essential formatting and mode information. There is no fluff or redundancy, making it highly efficient and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (10 parameters, no output schema, no annotations), the description is too sparse. It lacks information about required parameters, return values, error handling, or order lifecycle. This is a significant gap for a mutation tool that places real orders.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It does add meaning for amount and price parameters by specifying string format with examples, but it leaves the other 8 parameters (symbol, side, type, leverage, stopLoss, takeProfit, reduceOnly, clientOrderId) without explanation. This is insufficient for a 10-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Place a buy or sell order', using a specific verb and resource. This unambiguously identifies the tool's function and distinguishes it from sibling tools such as get_ticker, cancel_order, or set_leverage.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context: use this tool to place an order. It also notes that demo mode simulates orders, which is important context. However, it does not explicitly name alternatives or exclusion criteria, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_tickerA
  3.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only explains the symbol format but does not specify whether the returned price is the last trade, mid-price, or something else, nor does it mention authentication, rate limits, or error behavior. This is a notable gap 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant information. Every word adds value, making it highly concise and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (one parameter, no output schema), the description adequately covers the purpose and the main parameter format. It does not describe the response structure in detail, but the phrase 'current price' implies the core return value, and sibling tools add context for related operations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, but the description compensates effectively by providing concrete examples ('BTC/USDT or BTC/USDT:USDT for perpetual') that clarify the accepted patterns and explain the perpetual variant. This adds meaning beyond the raw regex 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 with a specific verb ('Get') and resource ('current price for a trading pair'). It also distinguishes itself from siblings like get_spread and get_multiple_tickers by focusing on the current price of a single pair, with examples for spot and perpetual markets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for a single trading pair's price but does not explicitly compare with alternatives such as get_multiple_tickers or get_spread. There is no clear 'when to use vs when not to use' guidance, leaving it somewhat implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_multiple_tickersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses the batching behavior and the 50-symbol limit (though also present in the schema), but it does not describe error handling, return format, or side effects. Since 'get' implies a read-only operation, this is adequate but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the action and resource. Every word earns its place with no superfluous information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one parameter and no output schema, the description provides sufficient operational context. It could be enhanced by mentioning the single-ticker sibling alternative, but the tool is straightforward enough that this omission does not create significant ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 defines the 'symbols' array with regex pattern and constraints, and the description does little beyond calling them 'symbols'. It ties the parameter to the tool's purpose but does not explain the symbol format or add meaningful detail beyond the schema, which has 0% coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get ticker data'), the resource ('for multiple symbols'), and the batching nature ('at once'). It distinguishes from the sibling tool get_ticker by emphasizing 'multiple' and the 50-symbol limit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'at once' implies batch retrieval for multiple symbols, which gives clear context for when to use it. However, it does not explicitly mention that for a single symbol one should use get_ticker, so no exclusions or alternatives are named.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_balanceA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It discloses key behavior: returns free, used, and total balance, and supports optional currency filtering. However, it does not mention authentication requirements, potential errors, or confirm that it is a read-only operation, which is a gap 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no redundant information. It front-loads the core purpose and immediately follows with the return details and parameter behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only balance tool without an output schema, the description adequately covers what the tool does and its primary parameter. It could be more explicit about return format or error handling, but the information provided is sufficient for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It does so by explaining that the optional 'currency' parameter filters the balance to a specific currency, and that omitting it returns all currencies. This adds meaningful context beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('account balance'). It also distinguishes the tool from siblings by describing its return values (free, used, total) and optional currency filter, making it unambiguous among the provided trading tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: to retrieve an account balance for all currencies or a specific one. It does not explicitly name alternatives or exclusions, but the context is sufficient to differentiate from sibling tools like get_positions or get_open_orders.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_modeA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. 'Get' clearly implies a read-only operation, and the description specifies the return value (demo/live). For a trivial getter, this is sufficiently transparent about behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that front-loads the action and result. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, no output schema, no side effects), the description is fully complete. It tells the user exactly what to expect and requires no 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 tool has zero parameters, so the baseline is 4. The description correctly omits parameter details, and there is nothing further to explain.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Get') and resource ('current trading mode'), and clarifies the output as demo/live. This fully distinguishes it from sibling tools, none of which mention trading mode.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is implied rather than explicitly stated: one would use this to check the environment before trading. There is no mention of when to use it vs alternatives, but given the sibling list, no alternative exists for this purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_positionsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of disclosing behavior. It uses 'get' which implies a read-only operation, and clarifies the scope (open positions with P&L). It does not detail return format or rate limits, but these are not critical for this simple action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, concise sentence that front-loads the action and key details. No unnecessary words or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple parameterless getter, the description is complete: it specifies what is returned (open positions with P&L) and the market scope. The lack of an output schema is not a gap since the description adequately states the result.

  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 document. The schema coverage is 100%, and the description adds no parameter information, which is acceptable per the baseline for 0 params.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the tool's purpose: retrieving open positions with P&L. It specifies the asset class (futures/perpetual only), distinguishing it from siblings like get_balance (balances) and get_open_orders (orders).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context by stating it is for futures/perpetual only, which signals when to use it. It does not explicitly name alternatives or when-not-to-use, but for a simple read-only getter this is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.