Server Quality Checklist

Tool Scores

• my_toolD
  1.1/5.0
  Behavior1/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 but fails completely. '自定义工具' gives no indication of whether this is a read/write operation, its side effects, permissions needed, or any behavioral traits.

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

  Conciseness2/5

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

  While technically concise with just three characters, this is under-specification rather than effective brevity. The description fails to convey necessary information, making it inefficient despite its short length.

  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?

  For a tool with one undocumented parameter, no annotations, and no output schema, the description is completely inadequate. It provides no functional context, parameter guidance, or behavioral information needed for proper tool invocation.

  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%, and the description provides no information about the single required parameter 'param'. It doesn't explain what 'param' represents, its format, or how it influences the tool's behavior.

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

  Purpose1/5

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

  The description '自定义工具' (custom tool) is a tautology that merely restates the tool name 'my_tool' without specifying what it actually does. It provides no verb, resource, or functional purpose, and doesn't distinguish it from sibling tools like 'add', 'hello', or 'server_info'.

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

  Usage Guidelines1/5

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

  The description offers no guidance on when to use this tool versus alternatives. There's no mention of context, prerequisites, or comparisons with sibling tools, leaving the agent with no usage direction.

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

• addC
  2.6/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. The description only states the mathematical operation without mentioning any behavioral traits like error handling, performance characteristics, or side effects. For a simple tool, this might be acceptable, but it lacks completeness for an agent to fully understand its behavior.

  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 front-loaded and wastes no words. For a simple addition tool, this brevity is appropriate and efficient, making it easy for an agent to parse quickly.

  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 (2 parameters, no annotations, no output schema), the description is minimal. It states the basic purpose but lacks details on usage, parameters, or behavioral context. While the tool is straightforward, the description doesn't provide enough information for an agent to confidently select and invoke it without additional inference.

  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%, so the description must compensate for the lack of parameter documentation. The description mentions '两个整数' (two integers), which aligns with the two parameters 'a' and 'b', but it doesn't add any semantic meaning beyond what's implied by the parameter names. It doesn't explain what 'a' and 'b' represent or any constraints beyond being integers.

  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 '两个整数的和相加' (sum of two integers) states what the tool does with a specific verb ('相加' - add/sum) and resource ('整数' - integers), but it's somewhat vague about the exact operation. It doesn't distinguish from siblings like 'hello' or 'server_info', but those are clearly different tools, so differentiation isn't critical here.

  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 prerequisites, context for use, or comparisons to other tools. The agent must infer usage solely from the tool name and description without explicit guidelines.

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

• helloC
  2.7/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 returns a greeting message as a string, but doesn't describe any behavioral traits such as side effects, error handling, or performance characteristics. For a simple tool, this might be minimal, but it lacks details like whether it's idempotent or has any constraints.

  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 concise and structured with clear sections for Args and Returns, using minimal text. It avoids unnecessary details, making it easy to scan. However, it could be more front-loaded by stating the purpose more prominently before the parameter details.

  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 (one optional parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It explains the basic input and output, but lacks usage context and behavioral details. For a simple greeting tool, this might be adequate, but it doesn't fully cover all aspects needed for optimal agent invocation.

  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 that the parameter 'name' is '要问候的名称' (the name to greet), which provides basic semantic meaning. However, with 0% schema description coverage and only one parameter documented in the description, it partially compensates but doesn't fully explain the default value 'World' or any validation rules. The baseline is 3 since the schema covers the parameter structure, but the description adds limited value.

  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 states the tool '返回问候消息' (returns a greeting message), which clearly indicates its purpose. However, it doesn't specify the exact format or content of the greeting beyond returning a string, and it doesn't differentiate from sibling tools like 'add' or 'my_tool' which have unrelated functions. The purpose is understandable but somewhat vague in execution details.

  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 for usage. Given that sibling tools include 'add' (likely for arithmetic) and 'my_tool' (unspecified), there's no indication of when a greeting tool is appropriate versus other operations.

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

• server_infoC
  2.7/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 full burden. It only states that it returns server information as a dict, without disclosing behavioral traits like whether it's read-only, has side effects, requires authentication, or has rate limits. For a tool with zero annotation coverage, this is insufficient transparency.

  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 but includes unnecessary structural elements like 'Args:' and 'Returns:' that don't add value beyond the schema. The core purpose is stated in one line, but the formatting could be more streamlined. It's not excessively verbose but has minor structural inefficiencies.

  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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'server information' includes, the format of the dict return value, or any behavioral context. For a tool that presumably provides system-level data, more detail is needed to be fully useful to an AI agent.

  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 with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information beyond what the schema provides, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.

  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 states '获取服务器信息' (get server information), which provides a basic verb+resource purpose. However, it's vague about what specific server information is retrieved and doesn't differentiate from sibling tools like 'hello' or 'my_tool'. The purpose is clear but lacks specificity and 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. The description doesn't mention any context, prerequisites, or exclusions for usage. With sibling tools like 'add', 'hello', and 'my_tool' available, there's no indication of when this specific tool is appropriate.

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