Server Quality Checklist

Tool Scores

• execute_hedge_arbitrage_strategyC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions 'Execute hedge arbitrage' which implies a trading action, but doesn't disclose critical details like whether this executes trades, requires specific permissions, has rate limits, involves risk, or what happens on failure. The description is insufficient for understanding the tool's behavior beyond basic purpose.

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

  Conciseness4/5

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

  The description is appropriately concise with a clear three-part structure: purpose statement, args section, and returns section. Each sentence serves a purpose, though the content within each section is minimal. No wasted words or unnecessary elaboration.

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

  Completeness2/5

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

  For a trading execution tool with no annotations, no output schema, and 2 parameters with 0% schema coverage, the description is incomplete. It doesn't explain what 'hedge arbitrage' means operationally, what the tool actually does (executes trades? calculates positions?), what the return summary contains, or any error conditions. The minimal description leaves too many questions unanswered for safe use.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate but provides minimal parameter semantics. It lists 'symbol' and 'quantity' with brief labels but no meaningful context about format, units, constraints, or examples. For a trading tool with 2 parameters, this leaves significant gaps in understanding what values are appropriate or how they're used in the arbitrage strategy.

  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 'Execute hedge arbitrage based on funding rate' which provides a general purpose (verb+resource), but it's vague about what 'hedge arbitrage' specifically entails and doesn't distinguish from sibling tools like 'find_arbitrage_pairs' or 'place_market_order'. It mentions funding rate but doesn't explain how this differentiates from other trading strategies.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 doesn't mention prerequisites, timing considerations, or when this strategy is appropriate versus other sibling tools like 'place_market_order' or 'find_arbitrage_pairs'. It provides no context about when this tool should or shouldn't be used.

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

• get_funding_rate_historyC
  2.4/5.0
  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 the tool 'gets' data (implying read-only) and describes basic parameters, but doesn't disclose important behavioral traits like rate limits, authentication requirements, data freshness/latency, error conditions, or pagination behavior. For a financial data tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.

  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 appropriately concise with a clear structure: purpose statement followed by Args and Returns sections. Each sentence serves a purpose, though the initial purpose statement could be more informative. The formatting with clear sections helps readability, though the content within those sections could be more substantial.

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

  Completeness2/5

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

  Given the complexity of financial data retrieval, no annotations, no output schema, and 0% schema description coverage, the description is insufficiently complete. It doesn't explain what the returned 'Funding rate data list' contains (structure, fields, units), doesn't mention time ranges or date filtering, and provides minimal context about the domain (perpetual contracts). For a tool that presumably returns time-series financial data, this leaves too many questions unanswered.

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

  Parameters3/5

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

  The description adds basic parameter information beyond the schema, which has 0% description coverage. It explains that 'symbol' is for 'Perpetual contract symbol' and 'limit' controls 'Number of records to return (default 100)'. However, it doesn't provide format examples for the symbol parameter, explain what constitutes a 'record', or clarify the ordering of returned records. With 2 parameters and 0% schema coverage, this provides some but incomplete 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 states 'Get funding rate history' which is a tautology that essentially restates the tool name 'get_funding_rate_history'. While it mentions the resource (funding rate history), it lacks specificity about what 'funding rate' means in this context or what time period is covered. It doesn't distinguish this tool from potential siblings that might also retrieve funding 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?

  The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include 'get_trade_history' and 'get_symbol_price', there's no indication whether this tool should be used for historical analysis, real-time monitoring, or specific trading contexts. No prerequisites, exclusions, or comparison to other tools are mentioned.

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

• cancel_orderC
  2.9/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 burden. 'Cancel a specific order' implies a destructive mutation, but lacks details on permissions needed, whether cancellation is reversible, rate limits, error conditions (e.g., if order already filled), or what happens on success/failure. The 'Returns' line is vague ('Cancellation result') without explaining format or meaning.

  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 appropriately sized and front-loaded with the core purpose first. The 'Args' and 'Returns' sections add structure without unnecessary verbosity. However, the 'Returns' line is overly vague ('Cancellation result'), which slightly reduces 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 a destructive tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks critical behavioral details (e.g., side effects, error handling), parameter specifics (e.g., symbol format), and clear return value explanation. The agent would struggle to use this reliably without external knowledge.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds basic semantics via the 'Args' section, explaining 'symbol' as 'The trading pair' and 'order_id' as 'Order ID to cancel', which clarifies purpose beyond just names. However, it doesn't specify format (e.g., symbol like 'BTC-USD'), constraints, or examples, leaving gaps.

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

  Purpose4/5

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

  The description clearly states the tool's purpose with 'Cancel a specific order' - a specific verb ('Cancel') and resource ('order'). It distinguishes from siblings like 'place_market_order' (creation) and 'get_open_orders' (retrieval). However, it doesn't explicitly mention what distinguishes it from other potential cancellation tools (none exist in 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?

  No guidance on when to use this tool versus alternatives. While siblings include 'get_open_orders' (for viewing orders) and 'place_market_order' (for creating orders), the description doesn't mention prerequisites (e.g., order must exist, be open), timing considerations, or when not to use it. The agent must infer usage from context alone.

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

• get_account_balanceC
  2.9/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 states what the tool does but lacks behavioral details such as whether it requires authentication, if it's read-only (implied by 'Get' but not explicit), rate limits, error conditions, or what 'balance info' includes (e.g., available vs. total balance). This is inadequate for a financial tool with zero annotation coverage.

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

  Conciseness4/5

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

  The description is front-loaded with the core purpose, followed by structured Args and Returns sections. It's efficient with no wasted sentences, though the Returns section is vague ('Asset balance info') which slightly reduces clarity but not conciseness.

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

  Completeness2/5

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

  Given the complexity (financial/cryptocurrency context), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain return values, error handling, or behavioral traits needed for safe use in a trading environment. This leaves significant gaps for an AI agent.

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

  Parameters3/5

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

  The description adds minimal semantics: it explains that 'asset' is a cryptocurrency symbol with an example (BTC). However, with 0% schema description coverage and only 1 parameter, this provides some value but doesn't fully compensate (e.g., no format constraints or valid symbols list). Baseline is 4 for 0 params, but here it's 1 param with partial info, so 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the verb 'Get' and the resource 'balance of a specific cryptocurrency asset', which is specific and unambiguous. However, it doesn't explicitly differentiate from siblings like get_symbol_price (which might return price rather than balance), so it misses full sibling distinction.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify if this is for checking available funds before trading (vs. get_open_orders) or for portfolio monitoring (vs. get_trade_history). No exclusions 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.

• get_open_ordersC
  2.9/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 of behavioral disclosure. It states the tool retrieves open orders but doesn't describe traits like whether it's read-only (implied by 'Get'), potential rate limits, authentication requirements, error handling, or data freshness. For a financial tool with no annotation coverage, this is a significant gap in transparency.

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

  Conciseness4/5

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

  The description is concise and well-structured, with a clear purpose statement followed by 'Args' and 'Returns' sections. Every sentence adds value, and there's no wasted text. It could be slightly improved by integrating the sections more fluidly, but overall it's efficient and front-loaded.

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

  Completeness2/5

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

  Given the tool's complexity (financial data retrieval), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return format (e.g., order details like price, quantity), error cases, or behavioral aspects like pagination or latency. For a tool with one parameter but significant contextual needs, this falls short of being fully helpful.

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

  Parameters3/5

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

  The schema description coverage is 0%, so the description must compensate. It adds minimal semantics by explaining 'symbol' as 'The trading pair', which clarifies the parameter's purpose beyond the schema's title 'Symbol'. However, it doesn't provide format details (e.g., 'BTC/USD'), examples, or constraints, leaving the parameter only partially documented.

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

  Purpose4/5

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

  The description clearly states the tool's purpose with 'Get open orders for a symbol', specifying both the verb ('Get') and resource ('open orders'). It distinguishes from siblings like 'get_trade_history' (historical trades) and 'place_market_order' (creating orders), though it doesn't explicitly mention these distinctions. The purpose is specific but could be more precise about what 'open orders' entails.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), context (e.g., real-time vs. cached data), or exclusions (e.g., not for closed orders). With siblings like 'get_trade_history' for past trades, the lack of comparative usage advice leaves the agent to infer when this tool is appropriate.

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

• get_trade_historyC
  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 carries the full burden of behavioral disclosure. It states it 'fetches' trades, implying a read-only operation, but doesn't specify permissions needed, rate limits, data freshness, or error conditions. This is inadequate for a tool that accesses historical trade data.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args/Returns sections are structured but slightly verbose; every sentence adds value, though it could be more streamlined (e.g., integrating parameter details into the main text).

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

  Completeness2/5

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

  Given the complexity of trading data, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on return format (e.g., what fields are in 'trade summaries'), error handling, and behavioral traits like rate limits or authentication needs, which are critical for this 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 description adds basic meaning for both parameters ('symbol: The trading pair' and 'limit: Number of trades to fetch'), which is valuable since schema description coverage is 0%. However, it doesn't provide format details (e.g., symbol syntax like 'BTC/USD'), constraints (e.g., limit range), or examples, leaving gaps in parameter understanding.

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

  Purpose4/5

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

  The description clearly states the verb ('Get') and resource ('recent trade history for a pair'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_open_orders' or 'get_funding_rate_history', which also retrieve trading data but for different resources.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or compare it to siblings like 'get_open_orders' for active trades or 'get_funding_rate_history' for other historical data, leaving usage context unclear.

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

• place_market_orderC
  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 carries the full burden of behavioral disclosure. It mentions 'place a market order' which implies a write operation with potential financial impact, but fails to disclose critical traits like authentication needs, rate limits, execution speed, or error handling. This is a significant gap 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.

  Conciseness4/5

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

  The description is front-loaded with the core purpose and uses a structured format with 'Args' and 'Returns' sections, making it efficient. However, the 'Returns' section is vague ('Order placement result'), and some sentences could be more informative, slightly reducing conciseness.

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

  Completeness2/5

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

  Given the complexity of a market order tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on return values, error cases, side effects (e.g., account balance changes), and how it fits with sibling tools, making it inadequate for safe and effective use.

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

  Parameters3/5

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

  The description lists three parameters (symbol, side, quantity) with brief examples (e.g., 'BTCUSDT', 'BUY or SELL'), adding some meaning beyond the input schema which has 0% description coverage. However, it doesn't fully compensate for the coverage gap by explaining parameter formats, constraints, or units (e.g., quantity as string vs. number), leaving ambiguity.

  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 ('place') and resource ('market order') with the action ('buy or sell'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'cancel_order' or 'execute_hedge_arbitrage_strategy', which prevents 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?

  No guidance is provided on when to use this tool versus alternatives like 'execute_hedge_arbitrage_strategy' for complex trades or 'cancel_order' for order management. The description lacks context about prerequisites, such as needing sufficient account balance or market conditions, leaving usage unclear.

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

• find_arbitrage_pairsB
  3.1/5.0
  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 offers minimal behavioral insight. It mentions criteria (funding rate, volume, stability) but doesn't disclose computational cost, rate limits, data freshness, or what 'analyze' entails. The return statement is vague ('List of qualifying arbitrage opportunities') without format or structure 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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured Args and Returns sections. Every sentence earns its place, though the Returns section is somewhat vague and could be more specific.

  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 4 parameters with 0% schema coverage and no output schema, the description does a decent job explaining parameters but lacks completeness. It doesn't cover behavioral aspects like performance, errors, or output format details. For a tool that likely involves data analysis, more context on limitations or assumptions would be helpful.

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

  Parameters4/5

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

  Schema description coverage is 0%, but the description compensates well by explaining all four parameters in the Args section with meaningful context: 'Minimum funding rate to qualify', 'Minimum 24hr volume in USDT', etc. It adds semantic value beyond schema titles like 'Min Funding Rate', though it could elaborate on units or typical ranges.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Find arbitrage pairs based on funding rate, volume, and rate direction stability.' It specifies the verb ('Find') and resource ('arbitrage pairs') with key criteria. However, it doesn't explicitly differentiate from siblings like 'execute_hedge_arbitrage_strategy' which might execute rather than find opportunities.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_funding_rate_history' for raw data or 'execute_hedge_arbitrage_strategy' for acting on findings. There's no context about prerequisites, timing, or exclusions.

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

• get_symbol_priceB
  3.1/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 burden for behavioral disclosure. It mentions the data source ('Binance') and return type ('Price information'), but lacks critical details like whether this is a real-time or delayed price, rate limits, authentication needs, error handling, or what specific fields the price information includes.

  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 appropriately sized and front-loaded, with the core purpose stated first in a clear sentence. The Args and Returns sections are structured but slightly verbose for a single parameter; every sentence earns its place by adding necessary information.

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

  Completeness3/5

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

  Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but has gaps. It covers the basic purpose and parameter, but lacks details on usage context, behavioral traits, and output specifics, which are important for a financial data tool.

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

  Parameters4/5

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

  With 0% schema description coverage and only one parameter, the description adds essential meaning by explaining the 'symbol' parameter as 'The cryptocurrency pair, e.g., BTCUSDT.' This clarifies the expected format beyond the schema's basic string type, though it could be more detailed about valid symbols or formatting rules.

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

  Purpose4/5

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

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current price of a cryptocurrency pair'), making it immediately understandable. However, it doesn't explicitly distinguish this tool from potential siblings like 'get_trade_history' or 'get_funding_rate_history' that might also return price-related data, preventing a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_trade_history' (which might include prices) and 'place_market_order' (which requires price data), there's no indication of when this specific price-fetching tool is preferred or what its limitations are.

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