Server Quality Checklist

Tool Scores

• get_natural_calendar_contextC
  2.6/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. It only states that it returns structured facts, implying a read-only operation, but provides no details about call behavior, return format beyond 'structured', potential costs, or side effects. This is insufficient for a complex multi-fact tool.

  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 sentence with no filler or redundant information. It is efficiently front-loaded with the action ('Return') and the key resource types. There is zero waste, which is ideal for conciseness.

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

  Completeness1/5

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

  The tool has no annotations, no output schema, and minimal description. It returns diverse types of information (phenology, moon phase, summer-dog, shu-jiu) but provides no explanation of what these are, how they are computed, or how the parameters influence them. The description is not complete enough for an agent to understand the tool's full behavior or outputs.

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

  Parameters1/5

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

  The input schema has 0% description coverage, and the description does not compensate. The two parameters, 'date' and 'timezone', are not explained in the description; it does not state how they affect the output, what formats are expected, or whether they are required. With no parameter semantics conveyed, the agent cannot confidently construct valid calls.

  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 returns specific types of natural calendar information (phenology, moon phase, summer-dog, shu-jiu facts) with a specific verb 'Return'. It is understandable and distinct from siblings like get_day_pillars and get_four_pillars, though it does not explicitly differentiate from get_calendar_context.

  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?

  No guidance is provided on when to use this tool versus alternatives. Sibling tools like get_calendar_context and get_day_pillars exist, but the description gives no context on selection criteria or prerequisites, leaving the agent to guess when this tool is appropriate.

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

• get_calendar_contextC
  2.8/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. It simply says 'Return... facts,' implying a read operation, but fails to mention any edge cases, parameter behavior, or output format. There is no context about what happens if date/timezone are omitted.

  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, focused sentence with no wasted words. It starts with the action verb and immediately states the core output, making it optimally 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?

  The tool is a simple read with two parameters and no output schema, so the description must explain the parameters and what the return value looks like. It does neither, leaving the agent without enough context to correctly invoke the tool or interpret results.

  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?

  The schema has 0% description coverage and the description does not mention the 'date' or 'timezone' parameters at all. While their names hint at their purpose, the description adds no additional meaning about format, defaults, or how they affect the returned facts, which is insufficient given the low 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 uses a clear verb 'Return' and names specific resources: 'solar-term and Twelve Duty calendar facts.' This distinguishes it from sibling tools like get_day_pillars and get_four_pillars, though terms like 'Twelve Duty' are unexplained jargon.

  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 gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states what it returns, leaving the agent to infer usage.

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

• get_four_pillarsB
  3.1/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. It mentions the 'fixed late-zi rule' but does not explain what that entails, nor does it address timezone handling, edge cases, or return format. The phrase 'exact civil-time' hints at precision but omits critical behavioral details needed for safe usage.

  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, front-loaded sentence that directly states the tool's purpose and rule. It contains no redundant words and earns its place, though it is brief. The structure is efficient and easy to parse.

  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?

  This tool has a moderate complexity (four-pillar calculation), but the description does not explain what 'four pillars' are, how the fixed late-zi rule is applied, or what the output looks like. With no output schema and no annotations, the agent is left without enough context to confidently invoke the tool correctly. The description is too minimal for the task.

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

  Parameters1/5

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

  The input schema has 0% description coverage, and the description does not compensate by explaining the parameters 'timezone' and 'local_datetime'. While the parameter names are self-explanatory to some degree, the description adds no information about their relationship or the 'fixed late-zi rule' in context, failing to help the agent understand required inputs.

  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 identifies the tool's function: returning exact civil-time four pillars using a specific rule ('fixed late-zi rule'). The verb 'return' and resource 'four pillars' are explicit and distinguish it from siblings like 'get_day_pillars' or 'get_calendar_context' by specifying a unique calculation method.

  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 for exact civil-time calculations with a particular rule, but it does not explicitly state when to use this tool versus alternatives such as 'get_day_pillars'. There are no exclusions or mention of alternative tools, leaving the agent to infer context from the rule mention alone.

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

• get_day_pillarsB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the burden of behavioral disclosure. It does disclose that only year, month, and day pillars are returned (and never an hour pillar), which is a meaningful constraint. However, it says nothing about side effects, return format, or error behavior, though for a simple query tool this may be sufficient.

  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, informative sentence that front-loads the main purpose. Every word earns its place, and there is zero redundancy or filler.

  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 (2 params, no output schema), the description provides a clear statement of what is returned. However, the complete lack of parameter semantics makes it less than fully self-sufficient. It is adequate but with a clear gap in parameter documentation.

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

  Parameters1/5

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

  The input schema has two parameters (date, timezone) with no descriptions, and schema description coverage is 0%. The description does not compensate by explaining what these parameters mean, their format, or how timezone affects the result. This leaves the agent without any guidance on how to fill the 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 a specific verb ('Return') and resource ('date-level year, month and day pillars'), explicitly excluding hour pillars. This distinguishes it from sibling tools like get_four_pillars, which likely includes the hour pillar.

  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 implied usage is that this tool is for retrieving date-level pillars, but there is no explicit guidance on when to use it versus alternatives or when not to use it. The 'never an hour pillar' clause hints at a distinction but does not name alternatives.

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