Server Quality Checklist

Tool Scores

• get_componentA
  4/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. It describes the return content as 'real code you can drop into the project and edit freely', but does not explicitly state it's a read-only operation or disclose any side effects, auth needs, or rate limits. Adequate but not comprehensive.

  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?

  Three sentences: first sentence states core purpose, second lists contents, third gives usage guidance and output nature. No wasted words, information is front-loaded.

  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 low complexity (2 params, no output schema), description explains return content (file contents, dependencies, install command) and states it's editable code. Lacks explicit structure or format of the returned source, but provides sufficient context for a simple tool.

  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 coverage is 100% with both parameters described. Description does not add significant extra meaning beyond the schema, such as constraints or format details. Baseline score 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?

  Description clearly states it fetches the full current source of a component from a specific library, listing included contents (file, dependencies, install command). It distinguishes from sibling tools like search_components, which find components, and list_registries, which list registries.

  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?

  Explicitly says 'Use this after search_components', providing clear context for when to use. It does not mention alternatives or when not to use, but the guidance is specific and helpful.

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

• list_registriesA
  4/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 only states it lists registries with basic fields, but does not disclose read-only behavior, potential empty results, or any side effects. Minimal behavioral info beyond purpose.

  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 sentence, front-loaded with the action, and no wasted words. It is appropriately sized for a simple 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?

  For a zero-parameter list tool with no output schema, the description covers the purpose, output fields, and usage order. It is fairly complete, though it could mention potential errors or empty results.

  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?

  There are no parameters, so baseline is 4. The description adds meaning about the output fields, which is useful for understanding the tool's output.

  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 verb 'List' and resource 'component libraries', and specifies the output fields (id, name, homepage). It distinguishes from sibling tools like get_component (detail) and search_components (search).

  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 advises to call this tool first to see available registries, providing clear context. It does not mention when not to use it, but the directive is strong enough to guide the agent.

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

• check_consistencyA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the tool performs static analysis (no side effects), returns concrete findings with pointers, and checks specific design dimensions. It does not discuss auth needs, rate limits, or performance, but the static nature and output type are adequately communicated for a read-only analysis tool.

  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 three sentences with no wasted words. It front-loads the core action, lists specific checks, describes the output, and ends with usage timing. Every sentence is informative and earns its place.

  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 lack of output schema, the description adequately explains that returns are findings with concrete pointers and lists the categories (border-radius, colors, dark-mode, icon/animation libraries). It covers the tool's complexity well, though it could detail the output structure slightly more. The usage context (after assembling from different libraries) adds completeness.

  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 input schema covers 100% of parameter descriptions, so the baseline is 3. The description adds context about the data source ('from get_component / search results') but does not deepen meaning beyond what the schema already provides (name and registry). It marginally hints at usage context but no new parameter semantics.

  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 uses a specific verb-statically analyze design clashes-and clearly identifies the resource (components from get_component/search). It enumerates specific clash types (border-radius scales, hardcoded colors, missing dark-mode, conflicting libraries), which distinguishes it from sibling tools like compare_components (direct comparison) or get_component (single component 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 explicitly states when to use the tool: 'Run this after assembling components from different libraries.' This implies the prerequisite actions (gathering components via get_component/search) and the post-assembly timing. It does not provide when-not-to-use scenarios or explicitly name alternatives, but the context is clear.

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

• compare_componentsA
  4.7/5.0
  Behavior4/5

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

  No annotations provided, but the description details what the tool returns (dependencies, file count, lines of code, install command, source preview). It is implied to be a read-only fetch and compare, but could explicitly state lack of side effects.

  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, efficiently conveying purpose, output, and usage guidance. Every word adds value; no redundancy.

  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 tool with 2 parameters and no output schema, the description provides complete context: what it does, what it returns, and when to use it. No gaps.

  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%, so the schema already documents both parameters. The description adds value by clarifying 'query' as component intent and 'registries' as optional subset of registry ids, enhancing understanding.

  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 compares components across libraries for a given intent, with examples like 'pricing table'. It distinguishes from siblings by contrasting with 'taking the first search hit' from 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 Guidelines5/5

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

  Explicitly says when to use: to choose the nicest implementation instead of taking the first search hit. This provides clear usage context and differentiates from search_components.

  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
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses synonym-aware behavior (modal/dialog, dropdown/select), the return format (registry, name, type, title, description), and clearly states it does NOT return source code. This is comprehensive and leaves no surprises.

  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 concise (four sentences), front-loads the core purpose, and efficiently uses examples and hints. Every sentence adds value without redundancy.

  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?

  Given the tool has 4 parameters, full schema coverage, no output schema, the description explains the return format (lightweight list with fields) and ranking. It is complete enough for an agent to use the tool effectively without additional information.

  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%, so baseline is 3. The description adds value by explaining the natural-language nature of the query, giving synonym examples, and clarifying optional filters with concrete values (ui, block, component, hook). It enhances understanding beyond schema alone.

  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 action: search across component libraries for components matching a natural-language query. It provides examples ('pricing table', 'date picker') and explicitly distinguishes from sibling tool get_component by stating it returns a lightweight list, not the source. This leaves no ambiguity about what the tool does.

  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 to 'Pick the best match, then call get_component to fetch its real code,' which provides a clear usage pattern. However, it does not explicitly state when not to use this tool or specify alternatives beyond get_component, so a slight deduction from a perfect score.

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