Server Quality Checklist

Tool Scores

• audit_siteA
  4.2/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavior: it is read-only, polices crawl rate (~1 req/sec), does not modify the site, and conditionally uses PageSpeed Insights. It details the types of checks and the structure of the response (summary and issues array), going well beyond typical descriptions.

  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 comprehensive yet well-organized, with clear sections for different check categories. It front-loads the core purpose and every sentence adds value, avoiding redundancy. Despite length, it remains focused and structured.

  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's complexity, no output schema, and three parameters, the description is remarkably complete. It explains the return schema in detail (per-pillar summary, issues array with fields like code, category, severity, etc.) and covers edge cases (e.g., conditional API key usage, redirect following).

  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 description adds meaning by explaining defaults (max_pages default 25, cap 100), conditions (speed_sample ignored unless API key set), and the expected format for site_url. This provides context beyond the schema's basic descriptions.

  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 'READ-ONLY, platform-agnostic site auditor' and enumerates the audit categories (SEO, GEO/AEO, speed). However, it does not explicitly differentiate from sibling tools like `speed_audit` or `preview_fix`, though the comprehensive scope implies it is the primary audit tool.

  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?

  The description explains that the tool works on any website and is read-only, providing clear context. However, it does not specify when to use this tool versus alternatives (e.g., `speed_audit` for speed-only audits), nor does it give explicit 'when not to use' guidance.

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

• propose_fixesA
  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 full burden. It clearly states it is read-only, never writes, and details fix classifications (deterministic, needs-value, manual, infra) and their nature. It lacks auth or rate limit info, but provides substantial behavioral context.

  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 front-loaded with key identity ('READ-ONLY safe-fix ADVISOR for ONE page') and each subsequent sentence adds substantive detail. It could be slightly more structured but is efficient without fluff.

  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 no output schema, the description thoroughly explains what the tool returns: concrete fix proposals with change details, visibility, issue codes cleared, safety notes, and exact edits or classification. It also mentions next steps (preview_fix), making it self-contained.

  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%, so baseline is 3. The description adds little to parameter meaning beyond the schema; it mentions 'codes' is optional but does not elaborate on value formats or constraints. However, the fix classification indirectly informs possible values.

  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 is a READ-ONLY safe-fix advisor for ONE page, with a specific verb ('audits', 'proposes') and resource. It distinguishes from siblings by focusing on one page and mentioning preview_fix for dry-run.

  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 recommends passing proposals to preview_fix before deciding, and states 'NEVER writes anything' to advise on safe usage. It provides clear context, though lacks explicit when-to-use vs alternatives like audit_site.

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

• preview_fixA
  4.6/5.0
  Behavior5/5

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

  Despite no annotations, the description fully discloses behavioral traits: read-only, no rendering, no writing, returns specific verdict categories (pass, idempotent, blocked, manual), and includes before/after. It clarifies the scope (structural safety gate, not pixel/visual). No contradictions.

  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 concise and front-loaded with the purpose. Each sentence adds value, though it could be slightly tightened. It is well-organized with important details upfront.

  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 no output schema, the description fully explains what the tool returns (verdict categories and before/after). It covers safety, action, and outcome. No gaps remain for effective use.

  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 only parameter 'fix' has a schema description stating it must include url and edit, which adds clarity beyond the schema's type definition. This helps an agent understand the required structure.

  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 is a read-only dry-run of a single fix proposal against current HTML. It specifies the action (preview), the resource (fix proposal), and the context (page's HTML). It distinguishes itself from siblings like propose_fixes and audit_site by focusing on validation before applying edits.

  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 (after propose_fixes to validate a fix) by referring to the object returned by propose_fixes. It also explicitly states the tool never modifies the site and is a structural safety gate. However, it does not provide explicit when-not-to-use scenarios or alternative tools.

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

• speed_auditA
  4.7/5.0
  Behavior5/5

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

  Discloses it is READ-ONLY, lists all activities (HTML heuristics always, optional PageSpeed Insights), and specifies return elements (Core Web Vitals, Lighthouse opportunities, recommendations with category 'speed'). No annotations exist, so the description fully informs behavioral traits without contradictions.

  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 well-structured sentences with no wasted words: first sentence states core purpose and nature, second details functionality and conditional behavior, third provides alternative. Every sentence is necessary and front-loaded with key information.

  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 a single parameter, no output schema, and no annotations, the description covers all needed context: tool action, scope, optional dependencies, return types, and relationship to sibling tool. It is complete for an agent to correctly invoke and interpret results.

  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 a single 'url' parameter described as 'The exact page URL to measure'. The description adds no further meaning about the URL parameter beyond what the schema provides, so baseline 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 performs a 'READ-ONLY speed-only audit of ONE page', specifying the resource (page URL) and action (audit). It distinguishes itself from the sibling tool 'audit_site' which handles whole-site, multi-pillar audits. The verb 'audit' combined with 'speed-only' and 'ONE page' provides precise purpose.

  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 states when to use (single page speed audit) and when to use alternative ('Use audit_site for a whole-site, multi-pillar audit'). Also notes conditional behavior based on PAGESPEED_API_KEY setting, guiding the agent on prerequisites and expected output variations.

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