Server Quality Checklist

Tool Scores

• design_search_stylesA
  4/5.0
  Behavior3/5

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

  Annotations already cover key behavioral traits (read-only, open-world, idempotent, non-destructive). The description adds useful context about the tool's parallel search behavior ('Runs image and web search in parallel and returns combined results'), which is not captured in annotations. However, it does not disclose other behavioral aspects like rate limits, authentication needs, or result format details.

  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 appropriately sized and front-loaded with the core purpose in the first sentence, followed by behavioral details. Every sentence earns its place by adding value without redundancy, making it efficient and well-structured.

  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 moderate complexity, rich annotations, and 100% schema coverage, the description is mostly complete. It covers purpose and unique behavioral traits. However, without an output schema, it does not explain return values (e.g., result format or structure), leaving a minor gap in 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?

  Schema description coverage is 100%, so the schema fully documents all parameters. The description does not add any additional meaning or semantics beyond what the schema provides (e.g., it doesn't explain parameter interactions or provide extra examples). Baseline score of 3 is appropriate when the schema does the heavy lifting.

  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 purpose with specific verbs ('Search for a specific aesthetic direction') and resources ('color palettes, typography, layouts, or animation references'), and distinguishes it from siblings by mentioning it runs 'image and web search in parallel and returns combined results'—unlike design_search_images which likely only searches images.

  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 context for when to use this tool ('Search for a specific aesthetic direction'), but does not explicitly state when not to use it or name alternatives among the sibling tools (e.g., design_search_images for image-only searches). The implied usage is strong but lacks explicit exclusions.

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

• design_search_imagesA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and behavior. The description adds context about the search scope (five specific sites) and result format (URLs, dimensions, source links), which is useful but doesn't provide rich behavioral details like rate limits or authentication needs. No contradiction with annotations.

  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 core functionality and followed by usage guidance. Every sentence earns its place with no wasted words, making it efficient and easy to parse.

  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 moderate complexity (3 parameters, no output schema), the description is mostly complete. It covers purpose, usage, and result format, but lacks details on error handling or pagination. With annotations providing safety context, it's sufficient but could be slightly enhanced for full 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?

  Schema description coverage is 100%, with each parameter well-documented in the schema. The description adds minimal value beyond the schema by implying the query should be UI-focused and specific, but doesn't explain parameter semantics in detail. Baseline 3 is appropriate given high schema coverage.

  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 searches for images across five specific design platforms (Dribbble, Behance, Awwwards, Mobbin, Pinterest) and returns specific data (image URLs, dimensions, source links). It distinguishes itself from sibling tools like 'design_search_references' and 'design_search_styles' by focusing on image search rather than references or styles.

  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 on when to use this tool by recommending specific UI terms (e.g., 'fintech dashboard dark mode') over vague ones (e.g., 'nice design'). It doesn't mention alternatives, but the context of sibling tools (design_search_references, design_search_styles) implies differentiation, and the guidance is clear for this specific use case.

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

• design_extract_tokensA
  4.4/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond what annotations provide: it specifies the extraction method ('using headless browser'), indicates it works on 'live websites,' and mentions the tool's purpose in a design workflow. While annotations already cover safety (readOnlyHint=true, destructiveHint=false) and reliability (idempotentHint=true, openWorldHint=true), the description enhances understanding of how the tool operates in practice.

  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 efficiently structured in two sentences: the first explains the core functionality, and the second provides usage context and integration with sibling tools. Every phrase adds value without redundancy, making it easy to parse and understand quickly.

  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 moderate complexity (3 parameters, no output schema) and rich annotations (covering safety and reliability), the description provides sufficient context for effective use. It explains what the tool does, how it fits with other tools, and its practical application. The main gap is the lack of output format details, but this is partially mitigated by the clear purpose statement.

  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?

  With 100% schema description coverage, the input schema already fully documents all three parameters (url, dark_mode, mobile). The description doesn't add any parameter-specific details beyond what's in the schema, so it meets the baseline expectation without providing extra semantic value.

  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 specific action ('Extract actual design tokens'), the resource ('from a live website'), and the method ('using headless browser'). It explicitly lists the types of tokens extracted (colors, typography, spacing, borders, shadows) and distinguishes itself from sibling search tools by focusing on extraction rather than discovery.

  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 on when to use this tool ('Give it any URL and get back the exact values used') and how it complements sibling tools ('Pairs well with the search tools — find inspiration, then extract tokens from sites you like'). This clearly differentiates it from the search-focused siblings (design_search_images, design_search_references, design_search_styles).

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

• design_search_referencesA
  4.4/5.0
  Behavior4/5

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

  Annotations cover read-only, open-world, idempotent, and non-destructive traits, so the description doesn't need to repeat these. It adds valuable context by specifying the search scope ('design platforms') and the types of content returned ('article titles, snippets, and links'), which helps the agent understand the tool's behavior beyond the annotations. No contradictions with annotations 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 front-loaded with the core purpose in the first sentence, followed by a clarifying second sentence on usage guidelines. Both sentences are essential, with no wasted words, making it efficient and well-structured for quick comprehension.

  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 moderate complexity (3 parameters, 100% schema coverage, no output schema), the description is largely complete. It covers purpose, usage guidelines, and behavioral context, though it could slightly enhance completeness by mentioning the lack of output schema or potential limitations like result freshness. However, it provides sufficient context for effective use.

  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 each parameter well-documented in the schema (e.g., query examples, site options, result limits). The description does not add significant semantic details beyond the schema, such as explaining parameter interactions or edge cases. Baseline score of 3 is appropriate as the schema carries the full burden.

  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 performs a 'web search scoped to design platforms' and specifies it 'returns article titles, snippets, and links.' It distinguishes from sibling tools like 'design_search_images' by emphasizing it's 'better than image search when you want case studies, write-ups, or design system documentation,' making the purpose specific and differentiated.

  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 on when to use this tool versus alternatives: it states it's 'better than image search when you want case studies, write-ups, or design system documentation,' which implicitly contrasts with sibling tools like 'design_search_images' and 'design_search_styles.' This gives clear context for selection among similar tools.

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