Server Quality Checklist

Tool Scores

• get_currency_pairsA
  4.2/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 does well by specifying the return format (list of CurrencyPair objects with detailed fields), mentioning potential errors (ValueError for API errors), and describing the type of information provided (constraints, trading rules). It doesn't mention rate limits, authentication requirements, or pagination behavior, but provides substantial behavioral context.

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

  Conciseness3/5

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

  The description is well-structured with clear sections (purpose, use cases, examples, returns, raises), but it's somewhat verbose. The Japanese text could be more concise while maintaining clarity. Each sentence adds value, but there's some redundancy between the use cases and examples sections.

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

  Completeness5/5

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

  Given the tool's complexity (read-only data retrieval with detailed output), the description is complete. It explains what the tool does, when to use it, what it returns (with detailed field descriptions), and potential errors. With an output schema available, the description appropriately focuses on semantics rather than repeating structured return format details.

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

  Parameters4/5

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

  The tool has 0 parameters with 100% schema description coverage, so the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and output. This is efficient and correct for a parameterless tool.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '対応している通貨ペア情報を取得します' (get supported currency pair information). It specifies the resource (currency pairs) and the action (get information). However, it doesn't explicitly differentiate from sibling tools like get_ticker or get_market_depth, which also provide market-related data.

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

  Usage Guidelines5/5

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

  The description provides excellent usage guidelines with three specific use cases: checking constraints before orders, calculating valid order parameters, and understanding trading rules. It also includes concrete examples like checking Bitcoin minimum order quantity and adjusting prices to tick sizes. This gives clear context for when to use this tool.

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

• place_orderA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well. It discloses authentication requirements ('APIキーとシークレットが設定されている必要があります'), indicates this is a market-facing order placement tool, and mentions potential errors (ValueError for authentication/API issues). It could improve by mentioning rate limits or order confirmation timing.

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

  Conciseness4/5

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

  The description is well-structured with purpose statement, usage context, examples, prerequisites, and parameter/return documentation. While comprehensive, some sections like the usage examples could be more concise. Overall, most sentences earn their place by adding meaningful information.

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

  Completeness5/5

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

  Given this is a complex order placement tool with 4 parameters, no annotations, and an output schema, the description is complete. It covers purpose, usage, prerequisites, parameter semantics, return values (OrderResponse details), and potential errors. The output schema handles return structure, so the description appropriately focuses on behavioral context.

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

  Parameters5/5

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

  The description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter's meaning: currency_pair examples with translations, order_type meanings ('bid'=buy, 'ask'=sell), price context (Japanese yen per unit for limit orders), and quantity examples (e.g., 0.01BTC). This fully compensates for the schema's lack of descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: '暗号資産の売買注文を発注します' (place buy/sell orders for cryptocurrency). It specifies the action (place orders) and resource (cryptocurrency), distinguishing it from siblings like cancel_order (cancel orders) or get_account_balance (retrieve balances).

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: '新規の売買注文を市場に出すために使用します' (to place new buy/sell orders to the market) and gives usage examples for buying Bitcoin, selling Ethereum, and placing limit orders. However, it doesn't explicitly state when NOT to use it or mention alternatives like market orders if available.

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

• get_account_balanceA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by disclosing authentication requirements, error conditions (ValueError for missing credentials or API errors), and return structure. It mentions retrieving balances for all currencies at once and checking available funds, which adds useful behavioral context beyond basic functionality.

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

  Conciseness4/5

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

  Well-structured with clear sections (purpose, usage examples, prerequisites, returns, errors). The description is appropriately sized for a tool with no input parameters but significant behavioral context. Minor deduction for some redundancy in usage examples that could be more concise.

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

  Completeness5/5

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

  Given the tool has no input parameters, an output schema exists, and no annotations are provided, the description is complete. It covers purpose, usage guidelines, prerequisites, return structure, and error conditions - everything needed for an agent to understand when and how to use this tool effectively.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so baseline would be 4. The description appropriately doesn't discuss input parameters since none exist, focusing instead on output semantics and usage context.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verbs ('取得します' - get/retrieve) and resource ('アカウントの残高情報' - account balance information). It distinguishes itself from siblings by focusing on account balance retrieval rather than order management, market data, or trading operations.

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

  Usage Guidelines5/5

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

  The description provides explicit usage scenarios with four concrete examples (checking available funds before trading, calculating total portfolio value, checking currency holdings, understanding investable amounts). It also specifies prerequisites (API key and secret must be configured in environment variables).

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

• cancel_orderA
  4.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 full burden and does well by disclosing authentication requirements, error conditions (ValueError for missing credentials or API errors), and the tool's behavior (cancels orders including partially executed ones, automatically determines currency pair if not specified). It doesn't mention rate limits or whether cancellation is reversible, but covers most critical behavioral aspects.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, usage, prerequisites, parameters, returns, errors) and every sentence adds value. It could be slightly more concise by combining some of the use case examples, but overall it's efficiently organized with no wasted text.

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

  Completeness5/5

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

  Given this is a mutation tool with no annotations, 2 parameters (one optional), and an output schema, the description provides excellent context. It covers authentication needs, error conditions, parameter semantics, usage scenarios, and references the output structure (CancelOrderResponse with order_id and balances). The presence of an output schema means the description doesn't need to detail return values, which it appropriately references instead.

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

  Parameters5/5

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

  The description adds significant value beyond the input schema, which has 0% description coverage. It explains that 'order_id' can be obtained from 'get_open_orders', provides the meaning and format of 'currency_pair' values with Japanese translations, and clarifies that currency_pair is optional with system fallback behavior. This fully compensates for the schema's lack of documentation.

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

  Purpose5/5

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

  The description clearly states the specific action ('cancel'), target resource ('unexecuted cryptocurrency trading orders'), and scope ('including partially executed orders'). It distinguishes from siblings like 'get_open_orders' (which lists orders) and 'place_order' (which creates orders) by focusing on cancellation of existing orders.

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

  Usage Guidelines5/5

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

  The description explicitly states when to use this tool ('for orders that are already placed and unexecuted'), provides three concrete use cases (price changes, wrong orders, long-unfilled orders), and mentions prerequisites (API key/secret must be configured). It clearly differentiates from alternatives by specifying it works on orders obtained from '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_market_depthA
  4.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 full burden and does well. It explains this shows market-wide data (not personal), describes the return structure (asks/bids with price/quantity), mentions error conditions (invalid currency pairs, API errors), and implies this is a read-only operation (no destructive language). It doesn't mention rate limits or authentication requirements, but provides substantial behavioral context.

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

  Conciseness4/5

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

  The description is well-structured with clear sections: purpose statement, differentiation from sibling tool, usage scenarios, examples, and formal parameter/return documentation. While comprehensive, some redundancy exists between usage scenarios and examples. Every sentence adds value, but it could be slightly more concise by integrating scenarios and examples.

  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 single-parameter read operation with an output schema, this description is exceptionally complete. It covers purpose, differentiation from siblings, multiple usage contexts, parameter semantics, return structure, and error conditions. The output schema existence means the description doesn't need to detail return values, and it appropriately focuses on when and why to use the tool.

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

  Parameters5/5

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

  The schema has 0% description coverage, so the description must fully compensate. It provides a dedicated 'Args' section explaining the single parameter 'currency_pair' with specific examples ('btc_jpy', 'eth_jpy', 'xym_jpy') and their meanings. This adds significant value beyond what the bare enum in the schema provides by explaining what these codes represent.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: '指定した通貨ペアの板情報を取得します' (get order book information for specified currency pairs). It explicitly distinguishes this from the sibling tool 'get_open_orders' by noting it shows market-wide order information rather than personal orders. The verb+resource combination is specific and unambiguous.

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

  Usage Guidelines5/5

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

  The description provides excellent usage guidance with three specific scenarios when to use this tool: analyzing market liquidity and buying/selling pressure, checking market depth before large orders, and identifying support/resistance levels. It also explicitly distinguishes when NOT to use it (for personal orders, directing to 'get_open_orders' instead). Three usage examples further clarify appropriate contexts.

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

• get_open_ordersA
  4.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 effectively describes key behaviors: it's a read-only operation (implied by '取得します'), requires API authentication ('環境変数にAPIキーとシークレットが設定されている必要があります'), and can raise errors for authentication or API issues. It also clarifies the scope ('一部約定を含む' - includes partially filled orders). The main gap is lack of rate limit or pagination information.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, usage guidelines, authentication requirements, parameters, returns, errors) and uses bullet points effectively. While comprehensive, it could be slightly more concise - some information in the Returns section could potentially be moved to an output schema. However, every sentence adds value and the structure helps with readability.

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

  Completeness5/5

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

  Given the tool's moderate complexity (1 parameter, read operation), the description provides excellent contextual completeness. It covers purpose, usage scenarios, authentication requirements, parameter semantics, return format (with detailed field descriptions), and error conditions. The presence of an output schema would reduce the need for the Returns section, but the current description stands well on its own as a complete guide for the agent.

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

  Parameters5/5

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

  The description adds substantial semantic value beyond the input schema. While the schema only shows currency_pair as an enum with three values, the description explains: 1) the parameter is optional ('指定しない場合、すべての通貨ペアの注文が返されます'), 2) provides human-readable labels for each enum value, and 3) clarifies the default behavior when not specified. With 0% schema description coverage, the description fully compensates with clear parameter documentation.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: '現在有効な（未約定の）暗号資産取引注文一覧を取得します' (Get a list of currently active/unfilled cryptocurrency trading orders). It specifies the verb '取得します' (get/retrieve) and the resource '注文一覧' (order list), and distinguishes it from siblings like cancel_order (which modifies orders) and place_order (which creates orders).

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidelines with three specific use cases ('使用例') and distinguishes when to use this tool versus alternatives. It mentions this is for viewing unfilled orders (including partially filled ones), while siblings like cancel_order are for modifying orders and place_order is for creating new orders. The guidance is comprehensive and practical.

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

• get_price_chartA
  4.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 effectively describes the tool's behavior: it retrieves data (not modifies), includes performance warnings about long periods causing processing delays, and specifies error conditions (ValueError for invalid dates or API errors). However, it doesn't mention rate limits, authentication requirements, or data freshness, leaving some gaps.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, use cases, guidelines, parameters, returns, errors) and uses bullet points for readability. While comprehensive, it's slightly verbose; some redundancy exists (e.g., repeating timeframe details in guidelines and Args). Every sentence adds value, but it could be more front-loaded.

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

  Completeness5/5

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

  Given the tool's complexity (4 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is highly complete. It covers purpose, usage, behavioral traits, parameter details, return structure (though output schema handles this), and error conditions. No significant gaps remain for effective tool invocation.

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

  Parameters5/5

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

  The schema description coverage is 0%, so the description must fully compensate. It provides comprehensive parameter semantics: currency_pair enum values with Japanese translations, timeframe enum values with explanations (e.g., '1': 1分足), and date format specifications (ISO format). This adds significant meaning beyond the bare schema.

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

  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: '指定期間の価格チャートデータを取得し、投資判断やトレンド分析に活用します' (retrieves price chart data for a specified period for investment decisions and trend analysis). It specifies both the action (retrieve) and resource (price chart data), and distinguishes itself from siblings like get_ticker (single price) or get_market_depth (order book).

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidelines with a detailed list of use cases (e.g., trend analysis, support/resistance identification) and timeframe-specific recommendations (e.g., '1分足・5分足: 数時間～1日分のデータが適切です'). It also includes warnings about performance implications for extreme date ranges, offering clear when-to-use guidance.

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

• get_tickerA
  4.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 full burden and does well by disclosing the tool's behavior: it provides current market price statistics, specifies what data is returned, mentions potential errors (ValueError for invalid currency pairs or API errors), and describes the return structure. It doesn't mention rate limits, authentication requirements, or data freshness, but provides substantial behavioral context for a read-only data retrieval tool.

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

  Conciseness4/5

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

  The description is well-structured with clear sections (purpose, usage scenarios, examples, Args, Returns, Raises) and every sentence adds value. It could be slightly more concise by combining some bullet points, but the information density is high and the structure helps with comprehension. No wasted sentences or redundant information.

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

  Completeness5/5

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

  Given the tool's moderate complexity (single parameter, read-only data retrieval), no annotations, and the presence of an output schema, the description provides excellent completeness. It covers purpose, usage guidelines, parameter details, return value structure, and error conditions. The output schema existence means the description doesn't need to fully document return values, but it still provides helpful semantic context about what each field represents.

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

  Parameters5/5

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

  The schema has 0% description coverage, so the description must compensate fully. It provides excellent parameter semantics: explains what 'currency_pair' represents, lists all valid enum values with clear explanations ('btc_jpy': Bitcoin/Yen, etc.), and provides the parameter in both the Args section and implicitly through usage examples. This completely compensates for the schema's lack of descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verb ('取得します' - get/retrieve) and resource ('ティッカー情報' - ticker information). It distinguishes from siblings by focusing specifically on current market price statistics rather than order management (cancel_order, place_order), account information (get_account_balance), or other market data (get_market_depth, get_price_chart).

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

  Usage Guidelines5/5

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

  The description provides explicit usage scenarios with bullet points detailing when to use this tool: checking current market prices and 24-hour price changes, reference for order pricing, and understanding market activity. It includes concrete examples (checking Bitcoin price, determining optimal order prices, analyzing 24-hour price ranges) that clearly differentiate when this tool is appropriate versus alternatives.

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

• get_trade_executionsA
  4.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 full burden and does well. It discloses authentication requirements (API key/secret), error conditions (ValueError for missing auth or API errors), and return behavior (newest-first ordering in '新しい順'). However, it doesn't mention rate limits, pagination, or whether this is a read-only operation (though implied by '取得'). For a tool with no annotations, this is strong but not exhaustive.

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

  Conciseness4/5

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

  The description is well-structured with purpose statement, usage guidelines, examples, prerequisites, and parameter/return documentation. Every section earns its place. However, the Japanese text is somewhat verbose (e.g., detailed Returns section that duplicates output schema info). It could be more concise by relying more on the output schema, but the information density is high.

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

  Completeness5/5

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

  Given 4 parameters with 0% schema coverage, no annotations, but with an output schema, the description is highly complete. It covers purpose, usage, prerequisites, parameter semantics, return structure (even though output schema exists), and error conditions. The Japanese examples and explanations provide rich context for an AI agent to understand when and how to use this tool effectively.

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

  Parameters5/5

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

  The schema has 0% description coverage (only titles), so the description must compensate fully. It provides detailed semantics for all 4 parameters: currency_pair (with enum values explained in Japanese), limit (with examples), start_date/end_date (format examples and temporal logic). The '指定しない場合' (if not specified) clauses explain default behaviors. This adds substantial value beyond the bare schema.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: '取得します' (retrieve) for '約定（成立）した取引履歴' (executed trade history) from 'あなたのアカウント' (your account). It distinguishes from siblings like get_open_orders (pending orders) and get_ticker (market prices) by focusing specifically on historical executed trades. The Japanese text is precise and unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit usage scenarios with four concrete examples (e.g., profit calculation, Bitcoin-only analysis, recent 20 trades, tax reporting). It also specifies when NOT to use it by mentioning prerequisites: '環境変数にAPIキーとシークレットが設定されている必要があります' (API key and secret must be set in environment variables). This gives clear context for when the tool is appropriate.

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