Server Quality Checklist

Tool Scores

• get_horoscopeC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions that longitude/latitude parameters enable true solar time conversion for more precise calculations, it doesn't describe what type of data is returned (format, structure), whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. For a 9-parameter tool with no annotation coverage, this is insufficient.

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

  Conciseness4/5

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

  The description is appropriately concise - two sentences that convey the core functionality and a key feature (true solar time conversion). It's front-loaded with the main purpose. However, the second sentence could be more tightly integrated with the first for better flow.

  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 complex tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what '运限信息（大限、流年等）' actually returns, the format of results, or how to interpret the output. The description should provide more context about the fortune/luck information being retrieved and what users can expect from the tool's response.

  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 schema already documents all 9 parameters thoroughly. The description adds minimal value beyond the schema - it mentions that longitude/latitude parameters are used for true solar time conversion, which is already indicated in the schema descriptions. No additional parameter context, constraints, or relationships are provided in 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 tool's purpose: '获取指定生辰在特定时间的运限信息（大限、流年等）' - it retrieves fortune/luck information for a specified birth time at a target date. It specifies the resource (birth information) and action (retrieve fortune data). However, it doesn't explicitly differentiate from sibling tools like 'calculate_ziwei' which might be related to Chinese astrology calculations.

  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 mentions supporting longitude/latitude parameters for true solar time conversion, but doesn't indicate when this tool should be chosen over 'calculate_ziwei' or other potential alternatives. There's no mention of prerequisites, use cases, or exclusion criteria.

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

• get_current_timeB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It mentions returning '详细的时间信息' (detailed time information), which gives some behavioral context about the output. However, it doesn't disclose other important traits like whether it's read-only, has side effects, requires permissions, or has rate limits—critical for a tool that might be time-sensitive or system-dependent.

  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 sentence that directly states the purpose and output. It's front-loaded with the core function ('获取当前系统时间') and adds just enough detail about the return value. There's zero wasted text, making it highly efficient.

  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 simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output type but lacks details on format, timezone handling, or error conditions. For a tool that returns system time, more context on precision or reliability would be helpful, though the low complexity keeps it from being severely incomplete.

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

  Parameters4/5

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

  The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics since there are none. A baseline score of 4 is appropriate as it doesn't mislead about parameters and aligns with the schema.

  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 current system time) with the verb '获取' and resource '系统时间'. It's specific about what it does, though it doesn't explicitly differentiate from sibling tools like 'calculate_ziwei' or 'get_horoscope', which appear to be unrelated time/astrology tools.

  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 any context, prerequisites, or exclusions. While the siblings seem unrelated (astrology calculations), the description doesn't clarify this distinction or provide any usage rules.

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

• calculate_ziweiA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that this is a calculation tool (not a read-only query) and mentions precision enhancements through true solar time conversion. However, it doesn't disclose important behavioral traits like whether this is a computationally intensive operation, potential rate limits, authentication requirements, or error conditions. The description adds some context but leaves significant gaps.

  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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality and output, while the second adds important precision capabilities. There's zero wasted language, and the information is front-loaded with the primary purpose stated immediately.

  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 complexity (8 parameters, astrological calculation), lack of annotations, and no output schema, the description is moderately complete. It covers the core purpose and precision features but doesn't address computational behavior, error handling, or output format details. For a calculation tool with this many parameters and no structured output documentation, more context would be helpful.

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

  Parameters4/5

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

  The input schema has 100% description coverage with detailed parameter documentation, so the baseline is 3. The description adds value by explaining the purpose of longitude/latitude parameters ('用于真太阳时转换' - for true solar time conversion) and mentioning that the tool supports these parameters for more precise calculations. This provides context beyond the schema's technical specifications, though it doesn't add detailed semantics for all parameters.

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

  Purpose5/5

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

  The description clearly states the specific action ('计算' - calculate), the resource ('紫微斗数星盘' - Zi Wei Dou Shu astrological chart), and the output ('完整的星盘数据' - complete chart data including twelve houses, stars, brightness). It distinguishes itself from sibling tools like get_current_time and get_horoscope by focusing on detailed astrological calculation rather than time retrieval or general horoscopes.

  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 mentioning support for longitude/latitude parameters and true solar time conversion for more precise calculations, suggesting this tool should be used when geographic precision matters. However, it doesn't explicitly state when to use this versus alternatives (like the sibling get_horoscope tool) or provide exclusion criteria for simpler cases.

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