Server Quality Checklist

Tool Scores

• toss_get_stocksA
  3.9/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the readOnlyHint annotation, including null conventions: delistDate is null if listed, leverageFactor null for common shares, and koreanMarketDetail null for overseas stocks. It also specifies the 200-symbol maximum, which is not in the annotations.

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

  Conciseness4/5

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

  The description is well-organized with a one-line summary, an Args section, and a Returns section. The Returns section lists 14 fields with brief explanations, which is comprehensive but not wasteful. Each part serves a clear purpose.

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

  Completeness4/5

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

  The tool has a complex return object with no output schema, and the description thoroughly documents all return fields and their null states, giving a complete picture. It does not mention error handling for invalid symbols, but that is acceptable for a read-only query tool.

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

  Parameters3/5

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

  The input schema already describes the 'symbols' parameter with the same format and example as the function description, achieving 100% coverage. The description repeats this information without adding new meaning, so it stays at the baseline.

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

  Purpose5/5

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

  The description opens with '여러 종목의 기본 정보를 조회합니다' (queries basic info for multiple stocks), clearly identifying the verb, resource, and scope. It distinguishes from sibling tools by focusing on '기본 정보' (basic info), separate from prices, orderbooks, or trades.

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

  Usage Guidelines3/5

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

  The description provides context by noting a 200-symbol limit and comma-separated format, which implies how to use it. However, it does not explicitly mention when to use this tool versus alternatives like toss_get_prices or toss_get_orderbook, nor does it state any exclusions.

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

• toss_get_exchange_rateA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the dateTime defaulting to current time and lists return fields, but does not disclose additional behavioral traits such as rate limits or error handling. With annotations doing the heavy lifting, a score of 3 is appropriate.

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

  Conciseness5/5

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

  The description is well-structured with an opening purpose statement followed by Args and Returns sections. Every sentence provides necessary information, and there is no wasted wording. It front-loads the purpose and uses a clear, scannable format.

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

  Completeness4/5

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

  The tool has no output schema, so the description compensates by listing all return fields (baseCurrency, quoteCurrency, rate, midRate, basisPoint, rateChangeType, validFrom, validUntil). It also explains the optional dateTime parameter. Missing are details on field types/units, but for a simple read-only lookup this is reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100% – each parameter is already described in the input schema. The description repeats the same semantics and adds no new meaning beyond stating that baseCurrency and quoteCurrency must differ, which is also in the schema. Therefore, it meets the baseline but does not exceed it.

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

  Purpose5/5

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

  The description explicitly states 'KRW ↔ USD 환율 정보를 조회합니다' (inquires KRW↔USD exchange rate information), using a clear verb and resource. It uniquely distinguishes this tool from all sibling tools, which focus on stocks, orders, accounts, and market calendars. The title '환율 조회' further reinforces the purpose.

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

  Usage Guidelines4/5

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

  The description clearly implies the tool is used when exchange rate information is needed, with no overlap among siblings. It lists required parameters (baseCurrency, quoteCurrency) and optional dateTime, giving context for invocation. However, it does not explicitly mention exclusions or alternative tools, so it stops short of a 5.

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

• toss_get_price_limitsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds KRX scope and return format but does not disclose potential errors or edge cases. This is adequate but not rich.

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

  Conciseness4/5

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

  The description is concise and front-loaded with the purpose, then includes Args and Returns sections. Some redundancy exists with the schema, but the structure is clear and information-dense.

  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?

  With only one parameter and no output schema, the description provides the full return structure (timestamp, upperLimitPrice, lowerLimitPrice, currency) and specifies the KRX scope. This is complete for a tool of this simplicity.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the description's Args section exactly repeats the schema's symbol description. No additional semantic meaning is provided beyond what the schema already contains, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states '특정 종목의 상한가/하한가를 조회합니다' (queries upper/lower price limits for a specific stock), using a specific verb and resource. This clearly distinguishes it from sibling tools like toss_get_prices (current prices) and toss_get_orderbook.

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

  Usage Guidelines4/5

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

  It specifies that the tool applies to '국내 KRX 종목' (domestic KRX stocks), providing a clear usage context. It does not explicitly name alternatives or exclusions, but the scope constraint helps the agent decide suitability.

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

• toss_get_sellable_quantityA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral detail about the return value: sellableQuantity is a decimal string, with KR being integer and US potentially fractional. This goes beyond the annotations' capability.

  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 highly concise, using a single-purpose summary sentence followed by clearly formatted Args and Returns sections. Every sentence contributes necessary information, with no unnecessary elaboration.

  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 2-parameter read tool with no output schema, the description provides return format and parameter provenance, which is largely sufficient. It could mention edge cases like pending orders affecting sellable quantity, but the current level of detail is adequate for correct invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both accountSeq and symbol fully described in the schema. The description's Args section merely repeats the schema text and adds 'required' markers already present in the required array, providing no new semantic meaning.

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

  Purpose5/5

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

  The description clearly states the tool retrieves sellable quantity for a specific account and symbol, using a specific verb ('조회합니다'). It distinguishes itself from sibling read tools by explicitly targeting '판매 가능 수량' (sellable quantity) as the resource.

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

  Usage Guidelines3/5

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

  The description implies usage context by specifying that accountSeq comes from toss_get_accounts and by detailing symbol formats. However, it does not explicitly compare with alternatives like get_holdings or explain when to prefer this tool, leaving usage guidance implied rather than explicit.

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

• toss_get_stock_warningsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds substantial context by enumerating all warning types (LIQUIDATION_TRADING, OVERHEATED, etc.), return fields (exchange, startDate, endDate), and the behavior of returning an empty array when no warnings exist.

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

  Conciseness4/5

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

  The description is well-structured with a clear front-loaded purpose and separate Args/Returns sections. However, it repeats the parameter description from the schema, which is redundant, though the detailed Returns section justifies the length.

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

  Completeness5/5

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

  Despite lacking an output schema, the description thoroughly explains the return structure, including fields and all possible warningType enum values. It also clarifies symbol formats for KRX and US, making the tool fully understandable for a simple 1-parameter operation.

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

  Parameters3/5

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

  The description includes an Args section that exactly mirrors the schema's description for the symbol parameter, providing no additional meaning beyond the schema. With schema coverage at 100%, the baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states '특정 종목의 투자 유의사항 및 경고 정보를 조회합니다' (retrieve investment cautions and warnings for a specific stock), using a specific verb and resource. It is distinct from sibling tools that handle market data, orders, or accounts, making its purpose unambiguous.

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

  Usage Guidelines3/5

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

  The description explains what the tool does but does not explicitly state when to use it versus alternatives. Usage is implied by its function (e.g., checking warnings before trading), but there is no explicit 'when-to-use' guidance or mention of alternative tools.

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

• toss_get_candlesA
  4.1/5.0
  Behavior4/5

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

  Annotations already identify this as a read-only, open-world, idempotent, non-destructive operation. The description adds behavioral context beyond this, including pagination via 'before'/'nextBefore', default values for 'count' and 'adjusted', and the return structure (candles[] with fields). This provides useful operational detail without contradicting the 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 concise and well-structured: a one-line purpose statement followed by a clearly labeled 'Args' list and 'Returns' section. Every element is necessary, and the format is easy to scan. No fluff 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?

  With no output schema, the description fully documents the return shape (candles[] with timestamp, openPrice, etc., and nextBefore). It also covers all 5 parameters, including optional ones with defaults and constraints. For a read-oriented tool with moderate complexity, this is complete and self-sufficient.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description repeats the parameter descriptions already present in the schema (e.g., interval, count, before) without adding new meaning. The 'Returns' section is valuable but does not contribute to parameter semantics. Thus, no additional value over the schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: '특정 종목의 캔들 차트 데이터를 조회합니다.' This specifies the verb (retrieve), resource (candle chart data for a specific stock), and scope (specific symbol). It distinctly differs from sibling tools like toss_get_prices or toss_get_trades, which focus on current prices or trade history.

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

  Usage Guidelines3/5

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

  The description does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusions or alternative tool recommendations. Usage is implied by the tool's name and description (needing candle chart data), but there is no direct guidance on when not to use it or which sibling would be better for different scenarios.

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

• toss_get_orderA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the return structure but does not disclose additional behavioral traits such as rate limits, error conditions, or dependencies. With annotations in place, the description provides adequate but not extra-rich behavior context.

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

  Conciseness5/5

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

  The description is concise and well-structured: a one-line summary followed by Args and Returns sections. It is front-loaded with the purpose and every line provides useful information without redundancy. The formatting makes it easy to scan and parse.

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

  Completeness5/5

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

  For a simple read-only tool with only two required parameters, the description fully covers both parameters (including their origin context) and provides a detailed list of return fields. Since there is no output schema, detailing the return values is essential and done thoroughly. It is complete 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.

  Parameters3/5

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

  The input schema has 100% description coverage, and the parameter descriptions in the schema are identical to the Args section in the description. The description repeats the same information (including the cross-references) without adding new semantics. Therefore, the description adds no value beyond the schema, warranting the baseline score of 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Retrieves detailed information for a specific order' with a specific verb (retrieves) and resource (specific order). It clearly distinguishes from sibling tools like toss_get_orders (which lists orders) and toss_create_order/toss_modify_order/toss_cancel_order (which perform other actions). The parameter cross-references to other tools further reinforce its specific role.

  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 on when to use this tool by specifying that accountSeq comes from toss_get_accounts and orderId from toss_create_order or toss_get_orders. This implicitly tells the agent to use this tool after obtaining those identifiers. It does not explicitly state when not to use it, but the context is clear enough.

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

• toss_get_orderbookA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds return structure (timestamp, currency, asks[], bids[]) and symbol format requirements (KRX numeric vs US ticker), which go beyond annotation metadata.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-line purpose, then clear Args/Returns sections, and examples. Every sentence adds necessary information with no 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?

  With only one parameter and no output schema, the description fully covers purpose, parameter format, return fields, and examples. It is self-contained for an agent to understand and invoke the tool correctly.

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

  Parameters3/5

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

  The schema description covers the symbol parameter 100%, and the description repeats the same explanation. No additional meaning is added beyond what the schema already provides, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool queries current orderbook (bid/ask depth) for a specific symbol, using a specific verb '조회' and resource '호가'. This distinguishes it from sibling tools like toss_get_prices and toss_get_trades.

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

  Usage Guidelines3/5

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

  The description provides context for market data retrieval but does not explicitly mention alternatives or when not to use this tool. Usage is implied by the examples, but there is no direct comparison to sibling tools such as toss_get_candles or toss_get_trades.

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

• toss_get_tradesA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds context about the result count limits (default 50, max 50) and the output fields, which helps set expectations beyond the 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 compact, front-loaded with the core purpose, and uses a clear Args/Returns structure. No redundant or unnecessary wording.

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

  Completeness5/5

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

  For a simple read-only trade listing tool, the description is complete: it specifies symbol formats, count limits, and the exact return fields, compensating for the lack of an output schema. The annotations cover safety, so no further behavioral caveats are needed.

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

  Parameters3/5

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

  Input schema covers both parameters with descriptions, defaults, and constraints (100% coverage). The description essentially repeats the schema information without adding new semantic meaning, so it meets but does not exceed the baseline.

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

  Purpose5/5

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

  The description clearly states '특정 종목의 최근 체결 내역을 조회합니다' (retrieve recent trade executions for a specific symbol), using a specific verb and resource. This differentiates it from siblings like toss_get_orderbook and toss_get_candles by focusing on executed trades.

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

  Usage Guidelines3/5

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

  It does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. Usage is implied by the resource name and description, which is enough to infer but lacks explicit guidance.

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

• toss_modify_orderA
  4.1/5.0
  Behavior4/5

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

  The description goes beyond the annotations by warning that this is a real trade (실거래 주의), restricting modification to PENDING/PARTIAL_FILLED orders, and detailing market-specific behaviors (KR quantity+price, US price only). It also discloses the high-value order confirmation flag. While annotations already mark destructiveHint=true, the description adds meaningful context about state prerequisites and safety checks, though it does not cover failure behavior or reversibility.

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

  Conciseness4/5

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

  The description is well-organized with a warning header, market rules, and a structured Args/Returns layout. It is front-loaded with the most critical caution. The Args list is somewhat redundant with the schema but serves as a useful inline summary; still, it could be more concise by omitting details already present in the schema. Overall, it is efficiently sized without unnecessary fluff.

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

  Completeness4/5

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

  Given the tool's complexity (6 parameters, market-specific rules, no output schema), the description is fairly complete. It explains the return value, parameter requirements, status preconditions, and the high-value flag. It does not mention error scenarios or what happens if the order is not in the correct state, but for a mutation tool with strong schema and annotation support, this is a minor gap.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description's Args list largely duplicates the schema, though it does add a few context cues such as 'accountSeq from toss_get_accounts response' and the positive-integer constraint. No new semantic value is added beyond what the schema already provides, so the score remains at baseline.

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

  Purpose5/5

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

  The description clearly states the tool modifies actual stock orders, limited to PENDING/PARTIAL_FILLED status, with specific market rules for KR and US stocks. The verb '정정합니다' (modify/correct) and the explicit resource ('주식 주문') make the purpose unambiguous and distinct from siblings like toss_create_order and toss_cancel_order.

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

  Usage Guidelines4/5

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

  The description specifies when this tool is applicable: only for orders in PENDING/PARTIAL_FILLED status. It also provides important usage constraints, such as US stocks cannot change quantity, and that confirmHighValueOrder is required for orders above 100 million KRW. However, it does not explicitly mention alternatives like 'use toss_cancel_order to cancel' or 'when not to use this tool', so it stops short of full exclusion guidance.

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

• toss_create_orderA
  4.2/5.0
  Behavior5/5

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

  The description goes far beyond the annotations (destructiveHint=true) by detailing that real money is involved, order types are limited, amount-based orders are only for US market buys, and the high-value confirmation flag. It also explains the idempotency behavior and return identifiers. This is rich behavioral context with no contradiction to the annotations.

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

  Conciseness4/5

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

  The description is front-loaded with a cautionary warning, followed by a well-organized Args section and a Returns section. It is long due to 10 parameters, but each item is relevant. Some redundancy with the schema exists, but overall it is structured and free of unnecessary fluff.

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

  Completeness5/5

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

  For a complex, dangerous tool with no output schema, the description is remarkably complete. It covers return values (orderId, clientOrderId), conditional requirements (price needed for LIMIT, confirmHighValueOrder for large orders), market-specific rules (KR vs US), and time-in-force options. No significant missing context.

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

  Parameters3/5

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

  The input schema has 100% description coverage, so the baseline is 3. The description largely repeats the schema's parameter descriptions, though it does add a cross-parameter constraint (quantity or orderAmount required) that is implicit in the schema. This does not substantially exceed the baseline because the schema already carries the main semantic weight.

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

  Purpose5/5

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

  The description clearly states the tool creates a stock order ("주문을 생성합니다") and explicitly warns that real funds are used. This distinguishes it from sibling tools like toss_modify_order and toss_cancel_order, which handle other order lifecycle operations.

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

  Usage Guidelines3/5

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

  The description provides clear context that this tool places new orders and warns about real trade execution, but does not explicitly mention when not to use it or point to alternatives such as toss_modify_order for corrections. Usage guidance is implied rather than directly stated, so it falls short of a higher score.

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

• toss_get_pricesA
  4.2/5.0
  Behavior4/5

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

  Annotations already mark this as read-only, idempotent, and non-destructive. The description adds useful behavior: it supports up to 200 comma-separated symbols and returns an array with symbol, timestamp, lastPrice, and currency. It doesn't describe error handling, but that's not required given the annotations.

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

  Conciseness4/5

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

  The description is efficient: a one-sentence purpose, then a structured Args/Returns breakdown. It is slightly redundant with the schema's parameter description, but keeps the overall length appropriate.

  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 read-only batch price tool, the description is complete: it covers the input format (comma-separated symbols, max 200), includes examples, and details the return fields. This compensates for the lack of an output schema.

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

  Parameters3/5

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

  The schema already documents the single parameter 'symbols' with full coverage. The description's Args section repeats the same information as the schema description, so it adds no new semantic meaning beyond what the schema provides.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb (조회) and resource (여러 종목의 현재가), and distinguishes it from sibling tools by focusing on batch current-price queries rather than orderbooks, trades, or candles.

  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 context is clear: this is for fetching current prices for multiple symbols at once, with a maximum of 200 symbols. It doesn't explicitly mention alternatives, but given the sibling tools cover different data types, the usage context is unambiguous.

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

• toss_get_buying_powerA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare the read-only, idempotent, non-destructive nature. The description adds context about the cash basis and the 'no unpaid balance' (미수 미발생) calculation, which clarifies the meaning of the returned value. It also explains the dependency on toss_get_accounts for accountSeq, providing valuable integration context beyond the 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 compact and well-structured: a one-sentence summary followed by clearly labeled Args and Returns sections. Every element adds value, including the source of accountSeq and the decimal-string format of the return. No filler or unnecessary detail.

  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?

  With no output schema, the description adequately explains the return values: currency and cashBuyingPower, including its meaning as cash-based and decimal string. It also covers the required input linkage to toss_get_accounts. Given the tool's simplicity, this is fully complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters already fully described. The description redundantly restates the parameters and adds '필수' (required), but does not add substantial new semantic meaning beyond the schema. It provides no extra syntax or format details beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool retrieves the cash-based buying power of a specific account, using a specific verb (조회) and resource (매수 가능 금액). It distinguishes itself from sibling tools by specifying the exact concept being queried (cash buying power, excluding unsettled credit).

  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 usage: target specific account (via accountSeq from toss_get_accounts) and currency (KRW/USD). It does not explicitly mention exclusions or alternatives, but the parameter linkage and return semantics imply when to use it: when you need cash-based buying power rather than holdings or sellable quantity. No explicit 'when not to use' is given.

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

• toss_get_commissionsA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not burdened with those. The description adds behavioral context by stating the return value is the raw API response ('API 응답 그대로 반환'), which is useful. No contradictions.

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

  Conciseness5/5

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

  The description is concise, with a clear purpose sentence followed by compact Args/Returns sections. No filler or redundant explanations beyond what is useful, and it is well-structured for quick parsing.

  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 read-only tool with one parameter and strong annotations, the description fully covers the necessary context: purpose, parameter source, and return behavior. No significant gaps remain.

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

  Parameters3/5

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

  The schema description covers the parameter fully (100% coverage), and the description repeats the same semantics without adding further details. Baseline 3 is appropriate since the schema already provides the meaning and source of the parameter.

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

  Purpose5/5

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

  The description clearly states 'Retrieves trade fee information for a specific account' with a specific verb (조회/retrieve) and resource (매매 수수료/transaction fees). It distinguishes itself from all sibling tools, none of which are fee-related, and specifies the account scope.

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

  Usage Guidelines4/5

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

  The description provides contextual guidance by noting the accountSeq should come from the toss_get_accounts response, implying this tool is used after listing accounts. It clearly implies when to use (query fees for a known account), though it does not explicitly mention alternatives or exclusions.

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

• toss_get_kr_market_calendarA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context by detailing the return structure (today with pre/regular/after market times, previous/next business day), which goes beyond the annotations and helps the agent anticipate the tool's output.

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

  Conciseness5/5

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

  The description is concise and well-structured, with a clear Args/Returns format. It front-loads the main purpose and every sentence is informative without unnecessary fluff.

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

  Completeness5/5

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

  Given the tool's simplicity—one optional parameter, read-only annotations, and no output schema—the description fully covers the necessary context. It clearly explains what the tool returns (market hours and business day fields) and the input format, making it complete for an agent to use correctly.

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

  Parameters3/5

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

  Schema description coverage is 100% for the single optional date parameter, so the schema already documents the format and default. The description repeats this same information (YYYY-MM-DD, default today), adding no new semantic value beyond what is already structured.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 action (조회/retrieve) and resource (국내 KRX 주식 시장 장 운영 시간 정보), making it immediately clear what the tool does. It explicitly names the market (KRX) and the type of information (market operating hours), which also differentiates it from the sibling US market calendar tool.

  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 that this tool is for the domestic KRX market, which implicitly distinguishes it from toss_get_us_market_calendar. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention 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.

• toss_get_us_market_calendarA
  4.3/5.0
  Behavior4/5

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

  Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds value by explaining null semantics (null means pre/after market not operating, regular market closed) and detailing the structure of the return object, which is not provided by an output schema.

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

  Conciseness5/5

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

  The description is well-structured with a summary line, a clear Args section, and a bulleted Returns list. It is front-loaded with the core purpose and each sentence earns its place without unnecessary verbosity.

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

  Completeness5/5

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

  Despite having no output schema, the description enumerates all return fields and their null semantics, making the tool's behavior fully transparent. With only one optional parameter and read-only annotations, the description is complete for this tool's complexity.

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

  Parameters3/5

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

  The schema already provides 100% coverage for the 'date' parameter, including its format, optionality, and default behavior. The description repeats this information without adding new meaning, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb ('조회합니다' - retrieves) and clearly states the resource: US stock market operating hours. It distinguishes from the sibling toss_get_kr_market_calendar by specifying 'US' and enumerates the specific return fields (pre-market, regular market, after-market, business days).

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

  Usage Guidelines4/5

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

  The description provides clear context: it retrieves US market hours for a specific date, defaulting to today if omitted. However, it does not explicitly mention when to choose this tool over alternatives, such as the KR market calendar sibling, so it stops short of a full 5.

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

• toss_cancel_orderA
  4.4/5.0
  Behavior4/5

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

  Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds a prominent warning that it affects real stock orders. It also specifies the status limitation and what is returned. This goes beyond annotations by detailing the operational scope and side effects, without contradicting them.

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

  Conciseness5/5

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

  The description is compact and well-structured: a warning, a one-sentence functional summary, a clear Args list, and a Returns section. Every sentence adds value, with no redundancy or filler. It is front-loaded with the critical caution and smoothly flows into operational details.

  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 cancel tool with only 2 parameters and no output schema, the description covers the effect, target status, parameter meanings, and return value. It lacks explicit error-handling details, but given the tool's simplicity and the rich annotations, the provided context is sufficient for an agent to select and invoke it correctly.

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

  Parameters4/5

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

  The input schema already fully covers both parameters (accountSeq and orderId) with descriptions. The description adds cross-reference context for accountSeq (linking to toss_get_accounts response) and restates the purpose of orderId. This enriches meaning beyond the schema, compensating for any schema brevity.

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

  Purpose5/5

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

  The description clearly states the tool cancels actual stock orders, specifying the verb 'cancel' and resource 'order'. It distinguishes itself from siblings by focusing on cancellation and noting the specific order statuses (PENDING/PARTIAL_FILLED). The title emphasizes real trading caution, reinforcing the purpose.

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

  Usage Guidelines4/5

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

  The description explicitly states that it cancels orders in PENDING/PARTIAL_FILLED status, giving a clear condition for use. It implies when not to use (for orders outside these statuses) but does not explicitly mention alternative tools like modify_order. This provides clear context without full exclusion guidance.

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

• toss_get_accountsA
  4.4/5.0
  Behavior4/5

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

  Annotations already mark readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds the concrete return fields (accountNo, accountSeq, accountType) and notes that accountSeq is used as the X-Tossinvest-Account header, plus a current limitation (only BROKERAGE).

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

  Conciseness5/5

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

  Two concise sentences plus a structured return list. No redundant content.

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

  Completeness4/5

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

  Given no output schema, the description provides the full return structure and usage context. It doesn't cover potential error cases or authentication, but for a 0-param list endpoint, this is sufficient.

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

  Parameters4/5

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

  No parameters exist; input schema is empty with 100% coverage, so description adds no parameter detail needed. Baseline 4 applies.

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

  Purpose5/5

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

  Description states '토스증권 계좌 목록을 조회합니다' (retrieve Toss Securities account list), a specific verb+resource. It also explains the returned accountSeq is needed for other API calls, distinguishing its role among sibling tools.

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

  Usage Guidelines4/5

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

  Implies usage before account/asset/order APIs by stating accountSeq is required for those calls. Does not explicitly name alternatives or exclusions, but the context is clear among the sibling list.

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

• toss_get_holdingsA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate readOnly, idempotent, and non-destructive, so the bar is lower. The description adds behavioral context by detailing the return structure (e.g., marketValue includes 'amountAfterCost - fee deduction') and the optional symbol filter, which are not captured by annotations. No contradictions with annotations.

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

  Conciseness5/5

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

  The description is well-structured: a one-sentence purpose statement, a prerequisite hint, then clearly labeled Args and Returns sections. Despite listing many return fields, every line provides necessary information. It is succinct for the tool's complexity and front-loaded with the essential purpose.

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

  Completeness5/5

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

  There is no output schema, but the description compensates with a detailed Returns structure including nested items[] fields and explanations of derived values. Combined with full annotations and complete parameter schema coverage, only minimal information is missing (e.g., pagination, error cases), which are not critical for this read-only tool.

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

  Parameters4/5

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

  Schema coverage is 100%, so a baseline of 3 applies. The description enhances parameters by explaining that accountSeq comes from toss_get_accounts and providing symbol filter examples ('005930' or 'AAPL'). It also clarifies the role of each parameter in the returned data, adding meaning beyond the schema.

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

  Purpose5/5

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

  The description opens with '특정 계좌의 보유 주식 현황을 조회합니다' (queries the holdings status of a specific account), which is a specific verb+resource with a clear scope. It differentiates from siblings like toss_get_accounts (accounts list) and toss_get_orders (orders), and the accountSeq prerequisite points to toss_get_accounts.

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

  Usage Guidelines4/5

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

  The description clearly tells users how to obtain the required accountSeq via toss_get_accounts, giving a strong usage context. It also explains that symbol is an optional filter for narrowing results. However, it does not explicitly state when not to use this tool or mention competing alternative tools beyond the prerequisite.

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

• toss_get_ordersA
  4.7/5.0
  Behavior5/5

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

  Annotations already indicate read-only and idempotent, and the description adds significant behavioral detail: the status groupings (OPEN includes PENDING, PARTIAL_FILLED, etc., CLOSED includes FILLED, CANCELED, etc.), pagination via cursor/nextCursor, and that cursor and limit only apply to CLOSED. It also documents the return structure. This goes well beyond the 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 structured with clear Args and Returns sections. Every bullet provides necessary information without redundancy, and the main purpose sentence is front-loaded.

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

  Completeness5/5

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

  With 7 parameters and no output schema, the description fully compensates by documenting all parameters, their types, requiredness, defaults, and the complete return object structure including pagination fields. This makes the tool well-understood.

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

  Parameters4/5

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

  The schema already provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds value by enumerating the exact statuses contained in OPEN and CLOSED, and clarifying that cursor/limit are only for CLOSED, which is not fully explicit in the schema's short enum 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 '특정 계좌의 주문 목록을 조회합니다' which is a specific verb (조회) and resource (주문 목록) with account context. It distinguishes from sibling toss_get_order by indicating a list of orders rather than a single one.

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

  Usage Guidelines4/5

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

  The description implies usage for retrieving orders for a specific account but does not explicitly name alternatives or exclusions. There is clear context but no when-not-to-use guidance, so it earns a 4 rather than 5.

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