Server Quality Checklist

Tool Scores

• diagnose_pageA
  4.3/5.0
  Behavior5/5

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

  The annotations only mark the tool read-only and open-world, so the description carries the behavioral burden and does it thoroughly. It discloses that the tool is slow, returns a job ID, requires polling via check_status, makes no extra API calls, filters one-off failures, and that savings are non-additive with median/spread reported. This is far more than the annotations alone provide.

  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?

  Every sentence earns its place: purpose, reliability rule, ranking rationale, overlap warning, and job-ID workflow are all distinct and valuable. The description is dense but appropriately scoped for a tool with no output schema, and it front-loads the core purpose before caveats.

  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?

  With no output schema, the description takes responsibility for explaining both output semantics and how to obtain results. It explains what is returned (ranked failures, savings with median/spread), how to collect them (check_status), and important interpretation rules (use order not sum). Nothing essential for correct calling and interpretation appears missing.

  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 baseline is 3 even without parameter details in the description. The description does add context tying 'runs' to distinct analyses and repeated failures, but most parameter meaning is already in the schema, so no additional compensation is needed.

  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 states a clear verb and resource: it reports what is failing on a page and ranks fixes by value, using Google's audit findings. It is unmistakably about page diagnosis, though it does not explicitly contrast itself with the sibling 'diagnose' or other report tools, so it stops short of full sibling differentiation.

  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 strong usage context: it only reports faults repeated in every run, ranks by what actually affects the performance score, warns that savings overlap, and explains the job-ID flow with check_status. It does not explicitly state when to prefer this over siblings like 'report' or 'compare', but the behavioral conditions are clear enough for most selection decisions.

  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.

• 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.

• check_statusA
  4.6/5.0
  Behavior5/5

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

  Even with readOnlyHint=true, the description adds valuable behavior: it always answers immediately, polling cadence, the hard wall-clock limit context, and the duplicate-start warning. This goes well beyond annotation hints and helps the agent avoid common mistakes.

  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 quite long but every sentence carries useful operational guidance. It is front-loaded with the core purpose and then gives necessary context and warnings. A little repetition with the schema exists, but it does not feel bloated.

  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 one optional parameter and no output schema, this description is complete. It explains the polling loop, the return behavior ('exactly what the tool would have returned'), and the most common pitfall. Nothing essential is missing.

  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 explains job_id and omitting it for the most recent job. The description reinforces this but does not add much new parameter-specific meaning beyond the existing schema text.

  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 a specific verb and resource: 'Collect a measurement that was handed back as a job.' It clearly distinguishes check_status from siblings by explaining that long-running tools return a job id and this tool retrieves the result with that id.

  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?

  It explicitly states when to call it ('Call this with that id, about every 15 seconds'), what to do after ('until it reports done'), and what not to do ('Do not start the same measurement again while one is running'). It also names the sibling tools that produce the job id, giving clear context versus alternatives.

  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.

• reportA
  4.8/5.0
  Behavior5/5

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

  The description goes far beyond the annotations by revealing async behavior, polling cadence, the server-side default reports folder, the requirement that directories already exist, the fact that nothing is overwritten, and the 150KB/font-embedding tradeoff. This is exactly the behavioral context an agent needs to act safely and correctly.

  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 long but every sentence carries operational weight: purpose, output, file handling, directory rules, polling, and performance. It is front-loaded with the core purpose and uses capitalized imperatives like "USE THE HTML" and "ASK THE USER WHERE THEY WANT IT FIRST" to surface critical action items.

  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?

  With no output schema and a complex async, file-writing workflow, this description covers everything an agent needs: return formats, job-ID polling, file-saving behavior, folder constraints, and when to avoid saving. No critical operational detail appears to be missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100%, the description adds substantial meaning beyond the schema: directory must be user-chosen and existing, html=false is for conversation-only answers, saving to a file is preferred because the HTML loses fonts in conversation, and paths must never be invented. This clarifies how to produce valid parameter values in real use.

  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 a clear definition of the tool: "The whole picture for a page in one call" and lists exactly what it returns — scores, real-user data, and failures ranked by fix value. It also distinguishes itself from siblings by being the aggregate report rather than a single-purpose check like check_pagespeed 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?

  The description gives strong operational context: it is slow, returns a job ID, requires polling via check_status, and should be used when the user wants a complete picture. It also gives explicit instructions about asking the user for a save location beforehand and setting html=false when only a conversational answer is needed. It does not explicitly name sibling tools as alternatives for narrower cases, so it stops short of a full 5.

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

• check_pagespeedA
  4.9/5.0
  Behavior5/5

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

  The description goes well beyond the readOnlyHint annotation by disclosing rate limiting, repeated polling, min-max spread, job ID behavior, timing, and honest degradation if time runs out. This rich operational detail is exactly the kind of context that helps an agent behave correctly.

  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 long, every sentence conveys a decision-relevant fact: noise, rate limits, timing, job handling, and immediate-answer conditions. The main uncertainty point is front-loaded, and the structure builds logically from behavior to usage constraints.

  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 still mentions it returns a report and JSON figures. It covers latency, polling, job IDs, parameter behavior, and edge cases like time running out. An agent has enough context to call the tool and interpret results safely.

  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, but the description adds meaningful behavioral semantics for the parameters: runs=1 is noisy, runs=5 takes ~150 seconds, and strategy defaults to mobile because Google ranks on it. This goes beyond what the schema alone states.

  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 identifies the tool as measuring a page with Google PageSpeed Insights and reporting the median of distinct analyses with min-max spread. This specific verb-resource pair distinguishes it from the sibling tools by emphasizing the repeated-analysis uncertainty behavior.

  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?

  It explicitly warns against using runs=1 and quoting the noisy score, notes that `check_status` should be used to collect jobs, and explains when immediate answers are possible. This gives clear when-to-use and when-not-to-use guidance beyond a generic description.

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

• compareA
  4.9/5.0
  Behavior5/5

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

  Even though annotations already say destructiveHint=true and idempotentHint=false, the description explains the concrete consequences: the first call records a baseline, save_baseline replaces it, and repeated calls keep the same comparison point. It also discloses non-obvious behavior like only reporting a verdict when min-max ranges do not overlap, flagging Lighthouse version changes, and returning a job ID for async collection. This far exceeds what the annotations alone convey.

  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 longer than average, but every sentence carries high-value operational information: baseline recording, overlap-based verdicts, guaranteed figures, field-data exclusion, and async slowness. It is front-loaded with the tool's core purpose and ends with the critical job-ID/check_status detail. There is no filler or 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 non-trivial async comparison tool with destructive baseline behavior, this description is remarkably complete. It covers what the tool measures, how to use it correctly across multiple calls, what a verdict means statistically, what it does not cover (field data), and how to retrieve the result. There is no output schema, so the description's explanation of verdict semantics is essential and sufficient.

  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 meaningful semantic context beyond the schema: strategy is part of the baseline identity, first-call behavior is integrated with save_baseline's semantics, and the same URL/strategy pairing is what ties the comparison together. It does not add much about runs or urls, but the baseline-related clarification is genuinely valuable.

  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 a concrete question the tool answers ('did that change actually help') and immediately states the mechanism: measure now and compare against a saved baseline for the same URL and strategy. This clearly distinguishes it from sibling tools like field_data, report, and check_status, which would be used at different stages or for different 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?

  It gives explicit, actionable usage rules: the first call records the baseline and compares nothing, then you make the change and call again. It also warns that field data is not compared, that the tool is slow and returns a job ID, and that check_status is used to collect the verdict. This is strong when-to-use guidance that prevents misuse.

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