Server Quality Checklist

Tool Scores

• compareA
  4/5.0
  Behavior1/5

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

  Annotation Contradiction: the description clearly describes state-changing behavior — 'THE FIRST CALL ON A URL RECORDS THE BASELINE' and the save_baseline parameter replaces the baseline — while the annotations declare readOnlyHint=true. This directly contradicts the read-only guarantee and would mislead an agent about 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence carries important operational detail: first-call behavior, statistical interpretation, version-change caveat, field-data limitation, and runtime cost. It is front-loaded with purpose but could be tightened.

  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?

  Despite having no output schema, the description covers all essential context: workflows, side effects, statistical interpretation, known version-change trap, field-data limitation, and performance cost. This is more than sufficient for an agent to invoke the tool 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% and all four parameters already have descriptions. The description adds meaningful behavioral context beyond the schema: first call records the baseline automatically, verdicts are only given when ranges do not overlap, and save_baseline semantics are tied to the workflow. This raises it above the baseline 3.

  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 starts with a clear user question ('did that change actually help') and then states the mechanism: measures now and compares against a saved baseline for the same URL and strategy. It is specific about the resource being compared and distinguishes the tool from siblings by explicitly noting it does NOT compare field data.

  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?

  Provides an explicit workflow: first call records the baseline, make the change, then call again. It also gives a clear when-not: field data is a 28-day window and cannot show a change made this week. The slowness warning is practical guidance that helps the agent decide whether to use this tool.

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

• check_pagespeedA
  4.5/5.0
  Behavior5/5

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

  Discloses significant behavioral traits beyond the readOnlyHint annotation: distinct analysis handling, caching behavior, time expectations, honest reporting, and JSON output. The description thoroughly explains how the tool behaves and why, adding substantial context beyond annotations.

  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 information-dense and front-loaded with the core purpose. It is somewhat long but every sentence adds behavioral or usage value. Could be slightly more terse, but the structure is logical and easy to follow.

  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 read-only tool with no output schema, the description explains the return value ('report and JSON') and covers key behaviors like median reporting and time constraints. It lacks a detailed breakdown of the report structure, but is complete for the tool's complexity.

  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 runtime implications (runs=5 takes ~150s), the warning about runs=1, and clarifying that 'distinct' analyses are used. This goes beyond the schema descriptions.

  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 measures a page with Google PageSpeed Insights and reports the median of several distinct analyses with min-max spread. This specific verb+resource+methodology distinguishes it from siblings like 'diagnose' or 'field_data'.

  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 usage guidance: warns against setting runs=1 for speed, explains the ~150s cost for runs=5, and notes that requesting harder won't speed it up. However, it doesn't explicitly name alternatives or state when to prefer this over sibling tools.

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

• diagnoseA
  4.5/5.0
  Behavior4/5

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

  Beyond the readOnlyHint and openWorldHint annotations, the description adds behavioral context: it actively checks live reachability and permissions, and it guarantees not to disclose the key. This is valuable non-redundant information about safety and operational behavior.

  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 action and outcome. Every phrase earns its place: it lists specific checks, clarifies the safety behavior, and gives a clear use case without unnecessary bulk.

  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 zero-parameter, no-output-schema diagnostic tool, the description is remarkably complete. It covers what is checked, what is not disclosed, and when to use it, leaving no major gaps for the agent to interpret.

  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 no parameters, and the schema already covers this fully with 100% coverage. The description doesn't need to explain parameter semantics; the baseline of 4 for zero-parameter tools applies, and no additional information is required.

  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 ('Report') and resource ('configuration and actual functionality'), listing concrete checks (key present, PageSpeed reachable, Chrome UX Report permitted). This distinguishes it from siblings like 'check_pagespeed' and 'diagnose_page' by focusing on configuration verification rather than performance or page-level diagnosis.

  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?

  It explicitly states when to use: 'tell a configuration problem apart from a slow or failing page before committing to a full check.' This gives clear context and implies alternatives (full check tools), though it doesn't name specific sibling tools or provide when-not-to-use scenarios.

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

• diagnose_pageA
  4.5/5.0
  Behavior5/5

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

  Beyond the readOnlyHint and openWorldHint annotations, the description reveals significant behavioral details: it only reports failures consistent across ALL analyses, provides median and spread for savings, explains the weighted ranking logic, and explicitly warns that savings do not add up. This goes far beyond the annotations in explaining the tool's actual behavior.

  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?

  Although the description is longer than average, every sentence adds critical information: purpose, consensus filtering, variance reporting, ranking logic, overlap of savings, and performance impact. It is front-loaded with the main purpose and remains tightly 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?

  For a tool with only two parameters and no output schema, the description covers all essential context: what it reports, how failures are determined, how to interpret savings, and the tool's speed/cost characteristics. This is complete enough for an agent to invoke and interpret results correctly.

  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 coverage, the schema already documents both 'runs' and 'urls'. The description reinforces the meaning of 'runs' by referring to 'distinct analyses,' but adds no new parameter-level detail. The baseline of 3 applies because the schema carries the descriptive 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 opens with 'Report what is FAILING on a page and rank it by what fixing it is worth,' which precisely states the tool's verb, resource, and output. It clearly distinguishes itself from siblings like check_pagespeed by focusing on failure diagnosis rather than overall speed.

  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 operational context by stating 'SLOW, like check_pagespeed, and costs no extra API calls,' which helps agents decide when it is appropriate to use. It doesn't explicitly name alternatives or exclusions, but the performance context is clear enough for informed use.

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

• explain_lcpA
  4.5/5.0
  Behavior5/5

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

  The description goes far beyond the readOnlyHint/openWorldHint annotations by disclosing non-obvious measurement behavior: phases are separate 75th percentiles that do not sum to LCP, shares are relative to phase total, and results are only for image-first visits. It also provides real-world gap ranges and cautions to quote the image share, offering exceptional transparency about output quirks.

  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?

  Although lengthy, the description is well-structured with no filler: it front-loads the purpose, then uses clear labels ('FAST', 'TWO THINGS NOT TO GET WRONG') to organize critical caveats. Every sentence adds essential behavioral or usage information, earning its place despite the length.

  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 there is no output schema, the description thoroughly explains what the tool returns conceptually: the four phases, percentile shares, and the image share caveat. It also covers prerequisites and limitations, making the tool's behavior predictable enough for an agent to select and invoke correctly with minimal missing context.

  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 schema already describes the only parameter (urls) as absolute HTTP(s) URLs defaulting to saved URLs. The description does not add any parameter-specific semantic detail beyond what the schema provides, so it meets but does not exceed the baseline for 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 uses a specific verb ('Break') and clearly identifies the resource (Largest Contentful Paint) and its decomposition into four distinct phases. It distinguishes itself from sibling tools by explicitly stating it turns one number into the owning phase, which is a unique function among diagnose, report, and field_data 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?

  The description gives clear usage context: it is fast, uses one Chrome UX Report call, and avoids Lighthouse noise, implying it is for quick LCP attribution. It also notes prerequisites (API key, real-user data) and that small sites may lack data, serving as a when-not indicator. However, it does not explicitly name alternative tools or say when to use them instead, so it misses full alternative guidance.

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

• reportA
  4.6/5.0
  Behavior5/5

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

  Beyond the sparse annotations (openWorldHint true, readOnlyHint false), the description discloses critical behavioral traits: it is 'SLOW, several minutes', it saves files when directory is passed, 'The folder must already exist; nothing is created and nothing is overwritten', and it differentiates between file-based HTML (embedded fonts, ~150KB) and conversation HTML (smaller). This is rich, non-contradictory context that greatly exceeds what annotations provide.

  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 long but front-loaded with purpose and return types, followed by imperative usage instructions. Each sentence provides necessary operational detail, though some redundancy exists (e.g., asking the user for a folder is emphasized multiple times). The structure is organized and effective, not bloated, so a 4 is appropriate.

  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—5 parameters, file output, HTML generation, speed, and user interaction requirements—the description covers all critical aspects: outputs, side effects, prerequisites, performance, and file/HTML behaviors. There is no output schema, so the explanation of return values ('readable report, HTML, and JSON') is sufficient. This is a complete and thorough description.

  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 baseline is 3. The description adds substantial meaning for 'directory' (must exist, user-named, not invented, can fall back to server folder) and 'html' (include or exclude based on user's need), which goes beyond the schema definitions. It does not add much for 'runs' or 'urls', but the added context for these key parameters justifies a 4.

  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 states the tool's function with a specific verb and resource: 'The whole picture for a page in one call: scores with their spread, real-user data if Google has any, and what is failing ranked by what fixing it is worth.' It clearly lists the three outputs (readable report, HTML, JSON) and distinguishes itself from siblings like check_pagespeed or diagnose by framing itself as the comprehensive aggregate report.

  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 gives clear operational context, including when to use the HTML ('USE THE HTML by saving it to a file the user can open or forward'), when to set 'html false', and explicitly instructs to 'ASK THE USER WHERE THEY WANT IT FIRST' before calling. It also mentions cost comparison to check_pagespeed. However, it does not explicitly state when not to use this tool or name alternative tools for specific scenarios, so it is not a perfect 5.

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

• field_dataA
  4.7/5.0
  Behavior5/5

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

  Despite readOnlyHint and openWorldHint annotations, the description adds valuable behavioral nuance: data may be absent for many sites, and absence is 'reported plainly and is not a failure.' It also explains the history flag produces a weekly p75 time series to reveal slowdowns over months. This goes beyond the annotations without contradicting them.

  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, each earning its place: defines what the tool does, explains the history option, and manages expectations about missing data. Front-loaded and no waste.

  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 two-parameter tool with a clear schema and safety annotations, the description covers the core purpose, behavioral limitations, and option semantics. It is sufficiently complete for an agent to decide when and how to invoke the tool.

  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 covers both parameters with descriptions (100% coverage), so baseline is 3. The description adds extra semantic meaning for the history parameter, explaining it as 'the weekly p75 time series' and its purpose for showing whether a site is getting slower over months. It doesn't add much for the urls parameter, but schema handles that.

  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 explains that the tool provides field data from the Chrome UX Report, and contrasts it with other evidence: 'the only evidence here about real visitors, and the only thing Google ranks on.' This distinguishes it from sibling diagnostic tools and states its core purpose.

  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?

  It conveys when to use it: for real-user data from CrUX, and notes that missing field data is expected for low-traffic sites. It also directs the history flag to enable the weekly p75 time series. However, it does not explicitly name alternative sibling tools or state when not to use it.

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