Server Quality Checklist

Tool Scores

• get_random_pagesB
  3.2/5.0
  Behavior2/5

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

  With no annotations, description should disclose behavior (read-only, rate limits, result variability) but only says 'random pages'. Missing critical transparency for a potentially non-deterministic tool.

  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?

  Efficient single sentence, no redundancy. Could be more structured (front-load key info), but compact.

  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?

  Adequate for a simple tool with no output schema, but gaps in behavioral transparency and parameter semantics reduce completeness.

  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?

  Schema description coverage is 50% (only pageType has description). Description adds no parameter context; fails to compensate for undocumented count parameter.

  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?

  Clearly states it returns random pages and gives use cases (divergent exploration, escaping local maximum), but doesn't explicitly distinguish from siblings like search_pages.

  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?

  Provides explicit scenarios for use (open-ended brief, escaping taste local maxima), but lacks when-not-to-use or alternative tools.

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

• get_page_detailsA
  3.6/5.0
  Behavior2/5

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

  No annotations provided, and the description does not disclose behavioral traits such as rate limits, authentication requirements, or side effects. It only describes the data returned.

  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?

  Single, well-structured sentence that front-loads the tool's purpose and lists all key features without unnecessary 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 one parameter and no output schema, the description adequately explains what the tool returns. Could be improved by mentioning error handling (e.g., 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 coverage is 100%, and the parameter 'slug' is described in the schema. The description adds no additional meaning beyond 'Page slug from search_pages'.

  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 'Full record for one page' and lists specific data elements (live URL, tags, screenshots, other pages, sections), distinguishing it from siblings like search_pages (list) and get_screenshot (single image).

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

  Usage Guidelines3/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 vs. alternatives like get_random_pages or search_pages. The description implies usage for obtaining complete page details but lacks exclusions or context.

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

• search_sectionsA
  4.1/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 full burden. It describes the search behavior: matches tags (all must match) and free text against company/title. It implies a read-only operation but does not disclose any side effects or return 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 consists of two concise sentences. The first sentence defines the tool's purpose with examples, and the second adds a critical constraint. Every word serves a purpose, with no unnecessary information.

  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 has 5 parameters, no output schema, and no annotations, the description covers the core functionality and a key constraint. However, it lacks details on pagination, return format, and idempotency, which would be beneficial for an agent.

  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 schema coverage is 60%. The description adds value by explaining the 'tags' parameter (all must match) and providing examples. It also clarifies that 'sectionType' values come from get_design_vocabulary, which helps the agent. Other parameters like 'query' and 'limit' are sufficiently covered by 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 that the tool searches individual page sections and lists examples (Hero, Pricing, Testimonials, etc.). It distinguishes itself from sibling tools like search_pages by focusing on sections rather than whole pages.

  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 explains the tool is 'perfect for mixing and matching' sections, implying a reuse scenario. It also states 'tags must ALL match', providing a key usage constraint. However, it does not explicitly mention when not to use or compare to alternatives.

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

• get_screenshotA
  4.3/5.0
  Behavior4/5

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

  No annotations, so description carries full burden. Explains that variant is ignored for sections, how full variant delivers in segments with iteration, and that section slugs capture the section. Does not cover error cases or rate limits, but sufficiently covers key 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?

  Two sentences, front-loaded with main purpose, then details. No wasted words. Could be slightly more structured (e.g., bullet points for variants) but overall efficient and readable.

  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 complexity and lack of output schema, the description covers the main use cases and parameter behavior. It warns about tall captures and iterating segments. Adequate for an agent to use correctly.

  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 schema already documents parameters. Description adds meaning: explains what each variant does, clarifies that variant is only for pages, and that segment is used for tall captures. Adds context beyond 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?

  Clearly states it returns a screenshot image of a page or section. Distinguishes between pages (with variants) and sections. The verb 'returns' and resource 'screenshot image' are specific. No sibling overlap mentioned but the purpose is distinct from other tools.

  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?

  Tells when to use: to see the design. Explains pages vs sections and variant choices. But does not explicitly say when not to use or mention alternatives from sibling list. The advice to view references before designing is helpful context.

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

• search_pagesA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses matching logic (ALL vs ANY) and output nature (compact summaries), adding value beyond structured data. No mention of rate limits or auth but acceptable for a read-like 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?

  Two well-structured sentences, front-loaded with key criteria, no wasted words. Every sentence adds value: search scope, filter logic, return type, and follow-up actions.

  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?

  Adequately covers purpose, filter behavior, output, and next steps for an 8-parameter tool with no output schema. Lacks pagination details but offset/limit are schema-defined. Missing prerequisites but acceptable.

  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?

  Adds meaning beyond schema by explaining matching semantics (styles/assets must ALL match, industries ANY) and output nature (compact summaries). Schema covers most parameters, but limit lacks description; however, description compensates with context.

  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 searches full SaaS pages by multiple criteria (style, industry, page type, stack, free text), distinguishes from siblings like search_sections and get_page_details by specifying the return type and follow-up actions.

  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?

  Provides clear guidance on when to use (searching for pages) and how to narrow results (styles/assets ALL match, industries ANY), and suggests follow-up tools (get_page_details, get_screenshot). Lacks explicit when-not-to-use but context is strong.

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

• get_design_vocabularyA
  4.5/5.0
  Behavior4/5

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

  The description accurately describes the tool's outputs (filter values and counts) and implies it is a read-only discovery operation. No annotations are provided, but the description is honest and covers the key behavior without contradiction.

  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 that efficiently conveys the tool's purpose and usage, with no fluff. It is front-loaded and every word contributes 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?

  Given the tool has no parameters, no output schema, and is a simple listing, the description is complete. It provides sufficient detail about the content (types of filters and counts) and its role in the workflow, making it self-contained.

  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 zero parameters, so no parameter documentation is needed. The baseline for 0 parameters is 4, and the description does not add parameter info because none exist.

  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 lists filter values with counts (verb 'lists', resource 'filter value') and explicitly distinguishes from sibling tools by indicating it should be called first to translate a design brief into search filters.

  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 guidance on when to use ('Call this FIRST') and the context (translate a design brief into concrete search filters). It does not explicitly mention when not to use, but the sibling tools are sufficiently differentiated.

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