Server Quality Checklist

Tool Scores

• get_card_infoC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is a read operation ('获取' - get), it doesn't describe any behavioral traits such as error handling (e.g., what happens if cardId is invalid), performance characteristics, rate limits, authentication requirements, or what 'detailed information' specifically includes. The description is minimal and lacks context beyond the basic purpose.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that states the purpose clearly without unnecessary words. It's appropriately sized for a simple lookup tool and front-loaded with the core action. However, it could be slightly more structured by including basic usage context, but it earns high marks for zero waste.

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

  Completeness2/5

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

  Given the tool's simplicity (1 parameter, no annotations, no output schema), the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., card stats, effects, rarity), how errors are handled, or any dependencies. For a tool with no structured output schema, the description should provide more context about return values to be fully helpful to an agent.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with cardId documented as '炉石传说卡牌ID' (Hearthstone card ID). The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain format, examples, or constraints for cardId. With high schema coverage, the baseline is 3, as the schema does the heavy lifting without extra value from the description.

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

  Purpose4/5

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

  The description clearly states the verb ('获取' - get/retrieve) and resource ('炉石传说卡牌信息' - Hearthstone card information) with specificity about what information is retrieved ('详细的' - detailed). It distinguishes from parse_deck_code (which likely parses deck codes) and search_cards (which likely searches multiple cards) by focusing on single-card lookup by ID. However, it doesn't explicitly contrast with siblings beyond the inherent difference in operation type.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use get_card_info versus search_cards (e.g., when you have a specific card ID vs. when you need to search by name/attributes) or parse_deck_code. There's no context about prerequisites, limitations, or typical use cases beyond the basic operation.

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

• search_cardsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions '支持模糊搜索' (supports fuzzy search) in the schema, but the description itself doesn't elaborate on this or other behaviors like response format, error handling, or rate limits. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it operates 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.

  Conciseness5/5

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

  The description is a single, efficient sentence: '根据卡牌名称搜索炉石传说卡牌信息' (Search for Hearthstone card information by card name). It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple search tool. Every part of the sentence contributes directly to understanding the tool's function.

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

  Completeness2/5

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

  Given the tool's moderate complexity (search functionality with fuzzy matching) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns (e.g., card details, IDs, or partial matches), how results are ordered, or any limitations. Without an output schema, the description should provide more context about the response to help the agent use the tool effectively.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting both parameters: 'cardName' (with fuzzy search support) and 'limit' (with default and range). The description doesn't add any additional meaning beyond what the schema provides, such as examples of fuzzy search behavior or context for the limit parameter. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

  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: '根据卡牌名称搜索炉石传说卡牌信息' (Search for Hearthstone card information by card name). It specifies the verb ('搜索' - search), resource ('炉石传说卡牌信息' - Hearthstone card information), and key input ('卡牌名称' - card name). However, it doesn't explicitly differentiate from sibling tools like 'get_card_info' or 'parse_deck_code', which likely have different purposes.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_card_info' (which might retrieve specific card details) or 'parse_deck_code' (which likely handles deck codes). There's no context about when this search tool is preferred over other methods or any prerequisites for its use.

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

• parse_deck_codeB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool parses deck codes and returns detailed information, but doesn't describe behavioral traits such as error handling (e.g., for invalid codes), performance characteristics, rate limits, authentication needs, or output format specifics. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose and output. It's front-loaded with the core action (parsing deck codes) and includes key details (card details and cover images) without unnecessary elaboration. Every word contributes to understanding the tool's function, making it highly concise and well-structured.

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

  Completeness3/5

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

  Given the tool's moderate complexity (parsing deck codes with optional stats) and lack of annotations and output schema, the description is minimally adequate. It covers what the tool does but lacks details on behavioral aspects, error handling, and output structure. Without an output schema, the description should ideally hint at return values, but it only mentions 'detailed deck information' vaguely, leaving gaps in completeness for effective agent use.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with clear documentation for both parameters (deckCode and includeStats). The description doesn't add any parameter-specific semantics beyond what the schema provides—it mentions returning card details and cover images but doesn't explain how parameters influence this. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

  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: '解析炉石传说卡组代码，返回详细的卡组信息，包括卡牌详情和封面图' (Parse Hearthstone deck codes, return detailed deck information including card details and cover images). It specifies the verb (parse), resource (deck codes), and output (detailed deck info with card details and cover images). However, it doesn't explicitly distinguish from sibling tools like get_card_info or search_cards, which appear to be about individual cards rather than deck parsing.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (get_card_info, search_cards) or specify contexts where this tool is appropriate (e.g., for analyzing deck compositions vs. looking up individual cards). There's no indication of prerequisites or exclusions, leaving usage entirely implicit.

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