Server Quality Checklist

Tool Scores

• pwmC
  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 full burden for behavioral disclosure. It states the tool 'adjusts PWM to maximum' which implies a write/mutation operation, but doesn't disclose any behavioral traits like side effects, permissions needed, error conditions, or what happens to existing PWM settings. The frequency=100 mention provides minimal context.

  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?

  Extremely concise single sentence that gets straight to the point. No wasted words or redundant information. However, the brevity comes at the cost of completeness - it's arguably too terse for a tool with no annotations or output schema.

  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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'maximum' means, what values are valid, what the tool returns, or what side effects occur. The single sentence leaves too many questions unanswered for proper tool understanding and 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?

  Schema description coverage is 100% with the parameter well-documented in the schema. The description adds minimal value beyond the schema - it mentions frequency=100 as an example but doesn't explain the semantic meaning of the frequency parameter or how it relates to 'maximum' PWM. Baseline 3 is appropriate given the schema does the heavy lifting.

  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 action ('调到最大' - adjust to maximum) and target resource (PWM), but it's vague about what '最大' means in context. It mentions frequency=100 but doesn't clarify if this is the maximum value or just an example. The description distinguishes from sibling tools (led, pico_info) by focusing on PWM control.

  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 explicit guidance on when to use this tool versus alternatives. The description implies this sets PWM to maximum, but doesn't specify use cases, prerequisites, or when not to use it. No comparison with sibling tools is provided.

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

• ledC
  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 full burden for behavioral disclosure. It states the action ('打开LED') which implies a write/mutation operation, but doesn't disclose whether this requires specific permissions, whether the change is persistent, what happens if the LED is already on, or what the response looks like. For a mutation 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.

  Conciseness4/5

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

  The description is extremely concise - a single phrase with embedded parameter example. While efficient, it might be too terse for optimal understanding. Every word earns its place, but the structure could be improved with clearer separation of purpose and parameter guidance.

  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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after execution, what errors might occur, or the broader context of LED control. The agent would need to guess about the tool's behavior and response format based on minimal 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?

  Schema description coverage is 100%, so the schema already documents the single parameter. The description adds minimal value by showing an example value ('on') in context, but doesn't provide additional semantics beyond what's in the schema's examples array. Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('打开LED' meaning 'turn on LED') and specifies the required parameter (state=on). It distinguishes from potential siblings by focusing on LED control rather than info retrieval (pico_info) or PWM control (pwm). However, it doesn't explicitly mention the resource being controlled beyond 'LED'.

  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 prerequisites, when this tool is appropriate versus pwm for LED control, or any constraints. The only usage hint is the parameter value 'on', but no context about when to use on vs off states.

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

• pico_infoB
  3.2/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. '查询' (query) implies a read-only operation, but the description doesn't explicitly state this or mention any other behavioral traits like authentication requirements, rate limits, error conditions, or what format the information returns. For a tool with zero annotation coverage, this is inadequate behavioral transparency.

  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 at just four Chinese characters ('查询Pico板信息'), which directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple query tool with no parameters, and the meaning is immediately clear 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?

  For a zero-parameter query tool with no annotations and no output schema, the description provides the minimum viable information about what the tool does. However, it doesn't explain what information is returned or in what format, which would be helpful given the lack of output schema. The description is complete enough to understand the basic purpose but lacks details about the tool's behavior and output.

  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 zero parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters since none exist, and it correctly doesn't attempt to describe non-existent parameters. The description focuses appropriately on the tool's purpose rather than parameter details.

  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 '查询Pico板信息' clearly states the tool's purpose as querying information about a Pico board, using a specific verb ('查询' - query) and resource ('Pico板' - Pico board). It distinguishes from sibling tools 'led' and 'pwm' which likely control hardware components rather than query information. However, it doesn't specify what type of information is retrieved, keeping 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. It doesn't mention when this tool is appropriate, what prerequisites might exist, or how it differs from the 'led' and 'pwm' sibling tools. The agent receives no usage context beyond the basic purpose statement.

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