Server Quality Checklist

Tool Scores

• powerC
  2.2/5.0
  Behavior1/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. '计算幂运算' only states the operation without any information on error handling, performance, mathematical constraints (e.g., large exponents), or output format. This is inadequate for a tool with no 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 extremely concise with a single phrase ('计算幂运算'), which is appropriately sized for a simple mathematical tool. It is front-loaded with the core purpose and has zero wasted words.

  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 mathematical nature and the presence of an output schema (which handles return values), the description is incomplete. It lacks context on usage, parameters, and behavioral traits, making it insufficient for an agent to fully understand when and how to invoke it correctly.

  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?

  Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about parameters beyond what the schema titles ('Base', 'Exponent') imply. For a tool with 2 parameters and 0% coverage, this is a significant gap.

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

  Purpose3/5

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

  The description '计算幂运算' (calculates power/exponentiation) states what the tool does with a clear verb+resource, but it doesn't distinguish from siblings like 'factorial' or 'sqrt' which are also mathematical operations. The purpose is understandable but lacks 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 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 like 'multiply' for repeated multiplication or 'sqrt' for square roots. The description offers no context, prerequisites, or exclusions for usage.

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

• multiplyC
  2.7/5.0
  Behavior1/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. The description only states the operation ('perform floating-point multiplication') without any information about precision, error handling, performance characteristics, or side effects. For a mathematical tool with zero annotation coverage, this is inadequate.

  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 with zero wasted words. It's appropriately sized for a simple mathematical operation and front-loaded with essential 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?

  Given the tool's low complexity (basic arithmetic), the presence of an output schema (which likely defines the return value), and the simple input schema, the description is minimally complete. However, it lacks behavioral context and parameter semantics, which are important even for simple tools, especially with no annotations provided.

  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 description coverage is 0%, meaning parameters 'a' and 'b' have no descriptions in the schema. The tool description adds no information about what these parameters represent (e.g., multiplicands, factors) or their expected behavior (e.g., order of operations, handling of special values like NaN or infinity). This fails to compensate for the schema 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 '执行浮点数乘法运算' (perform floating-point multiplication) clearly states the verb ('perform') and resource ('floating-point multiplication'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from its sibling tools (add, divide, etc.) beyond the obvious mathematical operation difference, which keeps it from a perfect score.

  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 like 'add' or 'divide'. It simply states what the tool does without context about use cases, prerequisites, or comparisons to sibling tools. This leaves the agent with minimal usage direction.

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

• sqrtC
  2.7/5.0
  Behavior1/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. '计算平方根' only states what the tool does, not how it behaves. It doesn't mention error handling (e.g., for negative inputs), performance characteristics, side effects, or output format. This leaves critical behavioral traits undocumented.

  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 phrase that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. It's perfectly front-loaded with the essential 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?

  Given the tool's mathematical simplicity and the presence of an output schema, the description is minimally adequate. However, with no annotations and 0% schema description coverage, it should provide more context about input constraints and behavioral characteristics. The output schema helps, but the description doesn't prepare the agent for potential errors or edge cases.

  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, so the description must compensate. '计算平方根' implies a number parameter but adds no semantic meaning beyond what's obvious from the tool name. It doesn't specify constraints (e.g., must be non-negative), units, or typical ranges. The single parameter remains largely undocumented.

  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 '计算平方根' (calculate square root) clearly states the tool's function with a specific verb and resource. It distinguishes from siblings like 'add' or 'multiply' by specifying the mathematical operation. However, it doesn't explicitly mention that it operates on a single number parameter, which would make it fully distinct from all siblings.

  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 sqrt over power (which could also calculate roots) or other mathematical operations. There's no context about input constraints (e.g., non-negative numbers) or typical use cases.

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

• subtractC
  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. It states the tool performs floating-point subtraction, which implies a mathematical operation, but doesn't disclose behavioral traits like error handling (e.g., for non-numeric inputs), precision limits, or whether it's read-only or has side effects. The description is minimal and lacks context on how the tool behaves beyond the basic operation.

  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 directly states the tool's purpose. It's appropriately sized for a simple arithmetic tool and front-loaded with the core functionality. There's no wasted text, though it could be slightly more informative without losing conciseness.

  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 low complexity (simple subtraction), two parameters with clear schema, and an output schema (implied by 'Has output schema: true'), the description is minimally adequate. However, it lacks details on usage context, error handling, or how it fits with siblings, which would improve completeness. For a basic tool, it meets the minimum but doesn't provide rich contextual information.

  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 adds minimal meaning beyond the input schema. It specifies 'floating-point' subtraction, which implies parameters 'a' and 'b' should be numbers, but the schema already defines them as type 'number'. With 0% schema description coverage, the description doesn't compensate by explaining parameter roles (e.g., minuend and subtrahend) or constraints. Baseline 3 is appropriate as the schema does the heavy lifting with clear property definitions.

  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 performs floating-point subtraction, which is a specific verb+resource combination. It distinguishes from siblings like 'add' and 'multiply' by specifying subtraction rather than other arithmetic operations. However, it doesn't explicitly mention the tool name 'subtract' in the description, keeping it at 4 rather than 5.

  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 'add' or 'divide', nor does it specify scenarios where subtraction is preferred over other operations. There's no context about input types or constraints beyond 'floating-point', which is implied but not explicitly contrasted with other tools.

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

• addB
  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 full burden for behavioral disclosure. It only states the operation type (floating-point addition) without mentioning error handling (e.g., overflow), precision limits, performance characteristics, or return format. For a computational tool with zero annotation coverage, this is insufficient behavioral 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 a single, efficient sentence in Chinese that directly states the tool's function with zero wasted words. It's appropriately sized for a simple arithmetic tool and front-loads the essential information without unnecessary elaboration.

  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 low complexity (basic arithmetic), 2 parameters, no annotations, but with an output schema present, the description is minimally complete. It states the operation type but lacks behavioral details and parameter context. The output schema reduces the need to explain return values, but more guidance would be helpful for a tool in a set of mathematical operations.

  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 0%, so the schema provides no parameter descriptions. The tool description doesn't mention parameters at all, failing to compensate for the coverage gap. However, with only 2 simple parameters (a, b) and an output schema present, the baseline is 3 as the schema defines the structure adequately for this basic operation.

  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 '执行浮点数加法运算' (perform floating-point addition operation) clearly states the verb 'addition' and resource 'floating-point numbers'. It distinguishes from siblings like subtract, multiply, and divide by specifying addition, though it doesn't explicitly contrast with them. The purpose is specific and unambiguous.

  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 like subtract or multiply. It states what the tool does but offers no context about appropriate use cases, prerequisites, or comparisons to sibling tools. This leaves the agent without usage direction 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.

• divideB
  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 mentions that 'b' must be non-zero, which is a critical constraint for division, but doesn't cover other behavioral aspects like error handling (e.g., what happens if b=0), performance characteristics, or return format. For a mathematical tool with zero 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.

  Conciseness3/5

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

  The description is brief with two sentences, but the structure is somewhat awkward with 'Args:' inline. It's front-loaded with the main purpose, but the parameter explanation could be better integrated. It avoids unnecessary verbosity but lacks polish in organization.

  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 (simple division), two parameters, no annotations, and an output schema present (which likely handles return values), the description is mostly complete. It covers the core operation and a key constraint (non-zero divisor), but could improve by explaining 'a' and error scenarios. The output schema reduces the need for return value details.

  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 description coverage is 0%, so the description must compensate. It adds semantic meaning by explaining that 'b' is the divisor and must be non-zero, which clarifies beyond the schema's generic 'B' title. However, it doesn't describe 'a' (the dividend), leaving one parameter undocumented. The description partially compensates but not fully for 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 as '执行浮点数除法运算' (perform floating-point division operation), which is a specific verb+resource combination. It distinguishes from siblings like add, multiply, and subtract by specifying division, though it doesn't explicitly contrast with them. The purpose is unambiguous but could be more differentiated.

  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 like multiply or other mathematical operations. It mentions that 'b' must be non-zero, which is a constraint but not usage context. There are no explicit when/when-not instructions or references to sibling tools, leaving the agent to infer usage based on the operation name alone.

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

• factorialB
  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. '计算整数阶乘' only states what the tool does, not how it behaves - no information about input constraints (negative numbers, large values), performance characteristics, error handling, or output format. The description is minimal and lacks behavioral 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 extremely concise - a single phrase that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it efficiently front-loaded with the essential 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 simple mathematical function with one parameter and an output schema, the description is minimally adequate. However, it lacks important context about input constraints and behavioral characteristics that would be helpful for an AI agent, especially given the complete absence of annotations.

  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 0% schema description coverage for the single parameter 'n', the description doesn't add any parameter-specific information beyond what's implied by the tool name. The schema shows 'n' is a required integer, but the description doesn't clarify valid ranges, constraints, or what happens with edge cases like n=0 or negative n.

  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 '计算整数阶乘' (calculates integer factorial) clearly states the verb (calculates) and resource (integer factorial), making the purpose immediately understandable. However, it doesn't distinguish this tool from its mathematical siblings like 'power' or 'multiply' beyond stating it's specifically for factorial 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. While the mathematical operation is clear, there's no mention of when factorial calculation is appropriate compared to other mathematical operations available in the sibling tools list.

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