Server Quality Checklist

Tool Scores

• get-component-docsB
  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 of behavioral disclosure. The description only states what the tool does (get documentation) but doesn't disclose any behavioral traits such as whether it requires authentication, has rate limits, returns structured data vs. raw text, or handles errors. For a tool with zero annotation coverage, this is a significant gap in transparency.

  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 sized and front-loaded: it starts with the main purpose, followed by usage scenarios in a bullet-like format. Every sentence earns its place by providing essential information. However, it could be slightly more structured (e.g., separating scenarios with clearer formatting) for a perfect 5.

  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 (simple lookup with 1 parameter), no annotations, no output schema, and low schema coverage, the description is minimally adequate. It covers the purpose and usage scenarios but lacks details on parameters, behavior, and output. It's complete enough for basic understanding but has clear gaps that could hinder effective use.

  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 1 parameter with 0% description coverage, meaning the parameter 'componentName' is undocumented in the schema. The description doesn't add any meaning beyond what the schema provides—it doesn't explain what 'componentName' should be (e.g., valid component names, format, case sensitivity). With low schema coverage (<50%), the description fails to compensate, leaving the parameter semantics unclear.

  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: '获取 Ant Design 特定组件的详细文档' (Get detailed documentation for specific Ant Design components). It specifies the verb ('获取' - get) and resource ('Ant Design 特定组件的详细文档' - detailed documentation for specific Ant Design components). However, it doesn't explicitly differentiate from sibling tools like 'list-components' or 'get-component-changelog', which would require a 5.

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

  Usage Guidelines4/5

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

  The description provides clear usage scenarios: '适用场景：1. 用户询问如何使用特定组件 2. 用户需要查看该组件的 api 属性' (Applicable scenarios: 1. When users ask how to use a specific component 2. When users need to view the component's API properties). This gives good context for when to use the tool. However, it doesn't explicitly mention when NOT to use it or name alternatives like 'list-component-examples' for examples instead of documentation, which would be needed for a 5.

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

• list-component-examplesB
  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 of behavioral disclosure. While it states what the tool does, it doesn't describe important behavioral traits like whether this is a read-only operation, what format the examples come in (e.g., code snippets, full implementations), whether there are rate limits, or what happens if the component doesn't exist. For a tool with zero annotation coverage, this is a significant gap.

  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 sized with three bullet points that efficiently cover usage scenarios. It's front-loaded with the core purpose statement. While the bullet points could be slightly more concise, there's minimal wasted text and the structure helps with readability.

  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 moderate complexity (single parameter, no output schema, no annotations), the description provides adequate purpose and usage context but lacks important details about parameters, return values, and behavioral characteristics. It's complete enough to understand when to use the tool but insufficient for reliable invocation without additional assumptions.

  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 input schema has 1 parameter with 0% description coverage, and the tool description doesn't mention the 'componentName' parameter at all. While the description implies a component name is needed ('特定组件'), it doesn't explain what format this should be in, whether it's case-sensitive, or provide any examples. With low schema coverage, the description fails to compensate for the parameter documentation 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 '获取 Ant Design 特定组件的代码示例' (Get code examples for specific Ant Design components), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get-component-docs' or 'list-components', which likely serve related but different purposes.

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

  Usage Guidelines4/5

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

  The description provides three explicit usage scenarios in Chinese: when users ask for component examples, when users want to implement functionality with examples, and when generating pages needing component code. This gives clear context for when to use the tool. However, it doesn't mention when NOT to use it or explicitly name alternatives among the sibling tools.

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

• get-component-changelogB
  3.3/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. While it mentions the tool lists changelogs, it doesn't disclose behavioral traits like whether it returns full or partial changelogs, how it handles invalid component names, if there are rate limits, or what format the output takes. For a tool with zero annotation coverage, this leaves significant gaps in understanding 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.

  Conciseness4/5

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

  The description is appropriately sized with two clear usage scenarios. It's front-loaded with the core purpose, followed by specific contexts. While efficient, the second scenario sentence is somewhat lengthy but still earns its place by providing valuable context.

  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 has no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers purpose and usage well but lacks critical information about parameters, return values, and behavioral constraints. For a tool with this complexity level, more comprehensive documentation is needed.

  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 1 parameter with 0% description coverage, and the description doesn't mention the 'componentName' parameter at all. While it implies a component is needed ('特定组件'), it provides no guidance on parameter format, valid values, or semantics. With low schema coverage, the description fails to compensate for the documentation 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 '列出 Ant Design 特定组件的更新日志' (list changelog for specific Ant Design components), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get-component-docs' or 'list-components', which might also provide component-related information but for different purposes.

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

  Usage Guidelines5/5

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

  The description provides explicit usage scenarios: '用户询问特定组件的更新日志' (when users ask about specific component changelogs) and '在知道用户 antd 版本的情况下...来决定是否需要升级依赖' (when knowing the user's antd version to decide if dependency upgrade is needed for functionality). This clearly indicates when to use this tool versus alternatives.

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

• list-componentsA
  3.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. It states the tool '仅返回可用的组件列表' (returns only the available component list), which implies a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, or returns structured data. The second sentence about editing files adds confusion as it describes post-call actions, not the tool's behavior itself, leaving gaps in 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 two sentences, but the second sentence ('调用此工具后，你必须编辑或添加文件...') is somewhat redundant and adds unnecessary detail about post-call actions, diluting focus. It's front-loaded with the primary purpose, but could be more concise by omitting the implementation guidance, which doesn't directly help tool selection.

  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 no annotations, no output schema, and 0 parameters, the description is moderately complete. It covers the purpose and usage context well, but lacks details on return values (e.g., list format) and behavioral aspects like error handling. For a simple list tool, this is adequate but has clear gaps in transparency and output expectations.

  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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is appropriate given the lack of parameters. A baseline score of 4 is applied as per rules for 0 parameters, as it doesn't need to compensate for any schema gaps.

  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: '仅返回可用的组件列表' (returns only the available component list). It specifies the resource (Ant Design components) and distinguishes it from siblings like get-component-docs or list-component-examples by focusing on listing rather than documentation or examples. However, it doesn't explicitly mention the verb 'list' in the first sentence, slightly reducing specificity.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidelines: '当用户请求一个新的用户界面（UI）使用 Ant Design 组件时使用此工具' (use this tool when the user requests a new UI using Ant Design components). It implies an alternative workflow (editing/adding files after calling) and distinguishes from siblings by focusing on initial listing rather than detailed docs or examples, though it doesn't name alternatives directly.

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