Server Quality Checklist

Tool Scores

• analyze_bazi_elementB
  3/5.0
  Behavior3/5

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

  Annotations already declare this as read-only, idempotent, and non-destructive, so the agent knows it's a safe analysis operation. The description adds value by specifying what the analysis includes (五行分数, 平衡度, 缺失五行), but doesn't provide additional behavioral context like rate limits, authentication needs, or output format details beyond the 'format' parameter.

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

  Conciseness5/5

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

  The description is extremely concise - a single Chinese sentence that efficiently states the core functionality. Every word earns its place with no wasted text, and the information is front-loaded with the main purpose.

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

  Completeness2/5

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

  For a 7-parameter analysis tool with low schema coverage (29%) and no output schema, the description is insufficient. It doesn't explain the complex Bazi analysis domain, doesn't clarify parameter relationships, and provides no information about return values or analysis methodology, leaving significant gaps for an AI agent.

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

  Parameters2/5

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

  With only 29% schema description coverage (2 of 7 parameters have descriptions), the description doesn't compensate for the significant documentation gap. It mentions '八字五行' analysis but provides no information about what the 7 parameters mean or how they affect the analysis, leaving most parameters semantically unclear.

  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: analyzing the strength of Five Elements in a Bazi chart, including scores, balance, and missing elements. It uses specific verbs ('分析' - analyze) and resources ('八字五行' - Bazi Five Elements), but doesn't explicitly differentiate from sibling tools like 'get_bazi_chart' or 'get_bazi_fortune' which might provide related information.

  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_bazi_chart' (which might provide the raw chart) or 'get_bazi_fortune' (which might provide fortune analysis), leaving the agent to guess about appropriate usage contexts.

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

• analyze_ziwei_palaceB
  3/5.0
  Behavior3/5

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

  Annotations already declare this as read-only, idempotent, and non-destructive, so the agent knows it's a safe, repeatable query operation. The description adds value by specifying it provides '详细信息' (detailed information) about specific palaces, which gives context about the depth of analysis. However, it doesn't mention rate limits, authentication needs, or what constitutes 'detailed information' in practice.

  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 Chinese sentence that immediately conveys the core purpose. There's zero wasted language or unnecessary elaboration. It's appropriately sized for what it communicates, though what it communicates is limited in scope.

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

  Completeness2/5

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

  For an 8-parameter tool with low schema coverage (38%) and no output schema, the description is inadequate. It doesn't explain what 'detailed information' means in the output, doesn't clarify the relationship between parameters, and provides no context about the Ziwei astrology system for users unfamiliar with it. The annotations help with safety profile, but the description leaves too many gaps for effective tool selection and use.

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

  Parameters2/5

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

  With only 38% schema description coverage (3 of 8 parameters have descriptions), the description carries significant burden but adds no parameter information. It mentions analyzing '特定宫位' (specific palaces), which aligns with the 'palace_name' parameter, but doesn't explain the meaning or significance of parameters like 'time_index', 'calendar', 'is_leap_month', or the various format/language options. The description fails to compensate for the low schema coverage.

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

  Purpose4/5

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

  The description '分析紫微斗数特定宫位的详细信息' clearly states the action ('分析' - analyze) and resource ('紫微斗数特定宫位' - specific Ziwei palace), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'get_ziwei_chart' or 'get_ziwei_fortune', which likely provide different types of Ziwei analysis.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_ziwei_chart' and 'get_ziwei_fortune' available, there's no indication whether this tool provides more detailed palace-specific analysis versus broader chart or fortune analysis. No context about prerequisites or typical use cases is mentioned.

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

• get_bazi_fortuneB
  3/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, indicating a safe, repeatable read operation. The description adds minimal behavioral context beyond this, mentioning it returns '详情' (details) but not elaborating on format, rate limits, or authentication needs. It doesn't contradict annotations, so a baseline 3 is appropriate given annotations cover core safety.

  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 in Chinese that directly states the purpose and scope ('包含大运、流年等详情'). It's front-loaded with no wasted words, making it easy to parse quickly. Every part of the sentence contributes 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 complexity (8 parameters, low schema coverage, no output schema) and annotations that only cover safety, the description is insufficient. It doesn't explain the return format, how parameters interact (e.g., 'birth_date' with 'calendar'), or provide examples. For a tool with rich cultural context like Bazi fortune-telling, more guidance is needed to ensure correct usage.

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

  Parameters2/5

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

  Schema description coverage is low at 38%, with only 3 of 8 parameters having descriptions in the schema. The description doesn't compensate by explaining any parameters, their relationships, or semantics (e.g., what 'time_index' represents, how 'calendar' affects calculations). It adds no value beyond the schema, failing to address the coverage gap.

  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 Bazi fortune information, including details like major cycles and yearly fortunes). It specifies the verb ('获取' - get) and resource ('八字运势信息' - Bazi fortune information), but doesn't explicitly differentiate from sibling tools like 'get_bazi_chart' or 'get_ziwei_fortune', which likely provide different types of Bazi/fortune information.

  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 (e.g., 'get_bazi_chart' for chart data, 'get_ziwei_fortune' for Ziwei fortune, 'analyze_bazi_element' for element analysis) or specify contexts where this tool is preferred. Usage is implied by the purpose but lacks explicit alternatives or exclusions.

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

• get_bazi_chartB
  3.2/5.0
  Behavior3/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 minimal behavioral context beyond this—it implies data retrieval but doesn't disclose rate limits, authentication needs, or output format details. However, it doesn't contradict annotations, so it meets the lower bar with annotations present.

  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 front-loads the core purpose and lists included components. It avoids redundancy but could be slightly more structured by separating purpose from details. Every word earns its place, making it appropriately concise.

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

  Completeness2/5

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

  For a tool with 7 parameters (4 with enums), low schema coverage (29%), and no output schema, the description is insufficient. It doesn't explain parameter meanings, output format, or behavioral nuances, leaving significant gaps in understanding how to use the tool effectively beyond its basic purpose.

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

  Parameters2/5

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

  Schema description coverage is low (29%), with only 2 of 7 parameters described in the schema. The description doesn't compensate by explaining any parameters—it mentions no parameter details, leaving most semantics undocumented. This is inadequate given the low schema coverage and multiple parameters with enums.

  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 Bazi chart information) and specifies the detailed components included: '年月日时四柱、十神、五行、地支藏干等详细信息' (four pillars, ten gods, five elements, hidden stems, etc.). It distinguishes itself from siblings like analyze_bazi_element or get_bazi_fortune by focusing on comprehensive chart generation rather than analysis or fortune-telling.

  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 analyze_bazi_element (for elemental analysis) or get_bazi_fortune (for fortune predictions), nor does it specify prerequisites or contextual constraints beyond what's implied by the parameters.

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

• get_ziwei_chartB
  3.3/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 agent knows this is a safe, repeatable read operation. The description adds no behavioral context beyond what annotations provide - no information about rate limits, authentication requirements, performance characteristics, or error conditions. However, it doesn't contradict the annotations, so it meets the minimum baseline with annotations present.

  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 Chinese sentence that clearly states the tool's purpose and the scope of information returned. Every word earns its place - it specifies what information is obtained and lists the key components included. No wasted words or redundant information.

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

  Completeness3/5

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

  For a complex tool with 12 parameters (3 required) and no output schema, the description is minimally adequate. The annotations cover safety aspects, and the schema has good documentation coverage. However, the description doesn't explain what format or structure the returned chart information will have, which would be helpful given the complexity of Ziwei charts and the absence 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?

  With 83% schema description coverage, the input schema already provides comprehensive documentation for most parameters. The description mentions '排盘信息' (chart arrangement information) which implies the parameters are for birth data input, but adds no specific guidance about parameter interactions, default behaviors, or special considerations beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '获取紫微斗数排盘信息' (get Ziwei Dou Shu chart information). It specifies the resource (Ziwei chart) and the scope of information returned (twelve palaces, main stars, auxiliary stars, four transformations). However, it doesn't explicitly differentiate from sibling tools like 'get_ziwei_fortune' or 'analyze_ziwei_palace', which likely provide different aspects of Ziwei analysis.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to Ziwei and fortune analysis (get_ziwei_fortune, analyze_ziwei_palace, etc.), but the description doesn't indicate whether this is the primary chart generation tool versus more specialized analysis tools. No context about prerequisites or typical use cases is provided.

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

• get_ziwei_fortuneB
  3.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, so the agent knows this is a safe, repeatable read operation. The description adds valuable context by specifying what fortune information is included (大限, 流年, 流月, 流日, 流时), which goes beyond the annotations. It doesn't mention rate limits, authentication needs, or response format details, but with good annotation coverage, this is acceptable.

  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 clearly states the tool's purpose. Every word earns its place - it specifies what information is retrieved and what time periods are included. There's no wasted verbiage or redundancy.

  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?

  For a read-only tool with good annotations, the description provides adequate basic purpose information. However, with 8 parameters (some complex like time_index and calendar/is_leap_month interactions) and no output schema, the description should ideally provide more context about what the tool returns and how parameters work together. It's minimally complete but leaves significant gaps.

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

  Parameters2/5

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

  Schema description coverage is only 50% (4 of 8 parameters have descriptions in the schema). The description provides no additional parameter information beyond what's implied by the tool name. It doesn't explain relationships between parameters (e.g., how birth_date and query_date interact, what time_index represents, or what calendar and is_leap_month control). With low schema coverage, the description should compensate but doesn't.

  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 Ziwei fortune information) with specific details about what it includes (大限, 流年, 流月, 流日, 流时). It distinguishes this from sibling tools like 'get_ziwei_chart' (which likely provides charts rather than fortune details) and 'get_bazi_fortune' (which provides different fortune system information). However, it doesn't explicitly contrast with all siblings like 'analyze_ziwei_palace'.

  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 choose this over 'get_ziwei_chart' (for fortune vs. chart) or 'get_bazi_fortune' (for different fortune systems). There's no context about prerequisites or typical use cases beyond the basic function stated.

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

• list_fortune_systemsA
  3.6/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 agent knows this is a safe, repeatable read operation. The description adds no behavioral traits beyond this, such as rate limits, authentication needs, or output format details. It doesn't contradict annotations, but adds minimal value given the annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose with examples. It is front-loaded with the core action and resource, with no redundant or unnecessary words, 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.

  Completeness4/5

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

  Given the tool's low complexity (one optional parameter), rich annotations covering safety and idempotency, and no output schema, the description is reasonably complete. It clearly states what the tool does, though it could benefit from more usage guidance or output details. For a simple list tool, this is adequate but not exhaustive.

  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 the parameter 'detailed' fully documented in the schema as a boolean for outputting more information. The description adds no parameter semantics beyond what the schema provides, such as examples of what 'detailed' includes. Baseline 3 is appropriate since 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 verb '列出' (list) and the resource '所有可用的命理系统' (all available fortune-telling systems), with examples like '紫微斗数、八字、占星等' (Ziwei Doushu, Bazi, astrology, etc.). It distinguishes from siblings by focusing on listing systems rather than analyzing or getting charts/fortune, though it doesn't explicitly name alternatives. This is specific but lacks explicit sibling differentiation.

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

  Usage Guidelines3/5

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

  The description implies usage when needing to see available systems, but provides no explicit guidance on when to use this tool versus alternatives like 'analyze_bazi_element' or 'get_ziwei_chart'. It doesn't state prerequisites, exclusions, or named alternatives, leaving usage context inferred rather than clearly defined.

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