Server Quality Checklist

Tool Scores

• get_install_commandA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It describes what is returned (three install methods) but does not explicitly state that it is a read-only, non-destructive operation. Given the nature of a 'get' command, this is adequate but not fully transparent.

  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?

  Two sentences with no fluff. The key information (purpose, return format, options) is front-loaded and efficient.

  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?

  The description explains the three install methods and the optional package manager parameter. There is no output schema, but the description covers the return content adequately. Minor gap: no mention of error handling or edge cases like invalid slug.

  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 input schema already documents both parameters well. The description adds context about the return format but not much beyond the schema. Baseline of 3 is appropriate.

  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 it returns the exact install command for an appCN component, specifying three methods and the context of adding to a project. It distinguishes from sibling tools like get_component or list_components by focusing on installation.

  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 implies when to use this tool (when needing the install command) and mentions the three methods but does not explicitly state when not to use it or name alternatives. However, the context is clear enough for an agent to infer.

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

• list_componentsA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It implies a read-only operation by stating 'List', but does not explicitly confirm safety or disclose any behavioral traits beyond the return format. For a list tool, this is adequate but not exceptional.

  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 two sentences, front-loaded with the action, and every sentence adds value: first sentence states purpose and output, second sentence gives usage context with sibling tool.

  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 simplicity (list with one optional filter), the description is complete in terms of purpose, output, and sibling relationship. It could mention ordering or empty results, but these are minor omissions.

  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 coverage is 100% and the schema already describes the category parameter. The description adds value by explaining the enum values ('base' for broad mobile library, 'ai' for AI-native collection), providing context beyond the schema.

  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 it lists every appCN component, optionally filtered by category, and specifies the returned fields. It distinguishes from the sibling get_component by suggesting to start here and then call get_component for full details.

  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 explicit guidance: 'Start here to see what's available, then call get_component' indicates when to use this tool and when to use an alternative. It could be more thorough about other siblings like search_components, but the guidance is clear.

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

• get_componentA
  4.5/5.0
  Behavior4/5

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

  As no annotations are provided, the description carries the full burden. It discloses that the tool returns comprehensive component details and recommends installation practices. No contradictions or hidden side effects are present.

  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 (two sentences) yet informative, front-loading the main purpose and including usage advice without extraneous content.

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

  Completeness5/5

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

  For a simple tool with one parameter and no output schema or annotations, the description covers purpose, behavior, and usage guidance, making it fully sufficient for correct agent invocation.

  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?

  With 100% schema description coverage, the description adds value by providing examples of valid slugs and clarifying it is a unique identifier, going beyond the schema's minimal description.

  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 defines what the tool does: it provides everything needed to add and correctly use one appCN component, including docs, source files, dependencies, and install command. This distinguishes it from sibling tools like list_components and search_components.

  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 advises preferring the install command over manual file pasting to resolve dependencies, offering actionable guidance. However, it does not explicitly contrast with alternatives like get_install_command.

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

• get_design_guideA
  4.5/5.0
  Behavior4/5

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

  Given no annotations, the description fully carries the burden. It discloses the exact contents of the guide (motion, haptics, rules, etc.) and implies it is purely a read operation. There is no mention of side effects or permissions, but the tool is a simple reference document.

  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?

  Two sentences: first lists the detailed contents, second provides actionable guidance. No filler or redundancy. Information is front-loaded and every sentence adds value.

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

  Completeness5/5

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

  With no parameters, no output schema, and straightforward purpose, the description fully defines the tool's scope and output. It covers all necessary aspects for an agent to understand when and how to use it.

  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, and schema coverage is complete. The description does not need to add parameter semantics. Baseline score of 4 for no-parameter tools applies.

  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 the tool provides appCN's design guide including motion tokens, press-scale, haptics, variant API rules, accessibility requirements, and a 'what NOT to do' list. It distinguishes from sibling tools like get_component by specifying it is about the design system for React Native components.

  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 explicitly tells the agent to read this before writing or modifying any React Native component, and advises to never hand-type durations or easings but to use these tokens. It provides clear context on when to use this tool, though it does not mention specific alternatives.

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

• search_componentsA
  4.7/5.0
  Behavior4/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 that the tool returns 'ranked matches with their delight detail,' implying a safe read operation. However, it does not disclose any potential limitations like result count, pagination, or response structure. A bit more detail on behavior would be beneficial.

  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 two sentences that front-load the core purpose with examples. Every sentence adds value: the first defines the action and scope, the second provides workflow guidance. No wasted words.

  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 that the tool has a single required parameter and no output schema, the description is complete. It explains the input (intent/keywords), output (ranked matches with delight detail), and next step (use get_component). It lacks mention of result limits or sorting, but overall it's sufficient for agent understanding.

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

  Parameters5/5

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

  The single parameter 'query' is fully described in the schema. The description adds value by providing example intents/keywords ('chat input', 'voice indicator'), which helps the agent formulate proper queries. Schema coverage is 100%, and the examples enrich meaning beyond the schema.

  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 the tool's function: 'Find appCN components by intent or keyword' with concrete examples ('chat input', 'voice indicator'). It explicitly differentiates from sibling tool 'get_component' by directing the agent to use that for full source/docs.

  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 guidance: 'Use get_component on the best match for the full source and docs.' This tells the agent exactly when to use this tool versus the sibling, showing the workflow.

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