Server Quality Checklist

Tool Scores

• analyze_pagespeedC
  2.7/5.0
  Behavior2/5

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

  No annotations provided, and description lacks behavioral traits such as authentication, rate limits, or read-only nature. Only states outputs, not side effects or prerequisites.

  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?

  Single sentence conveying purpose and outputs efficiently. Front-loaded with key action, though could benefit from bullet points for readability.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No output schema exists, yet description omits response structure or example. For a tool returning complex data, this leaves ambiguity.

  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 33% (only url described). Description does not elaborate on parameters like strategy or categories beyond the schema enums and defaults, missing chance to add value.

  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?

  Description clearly states it analyzes a URL with PageSpeed Insights API v5 and returns specific outputs (scores, lab metrics, audits, recommendations). While it differentiates from siblings like analyze_pagespeed_batch by being single-URL, it does not explicitly contrast.

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

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives. With sibling tools like batch and comparison, explicit usage context would help.

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

• analyze_pagespeed_batchC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose all behavioral traits. It mentions concurrency limits and API version, but fails to mention authentication requirements, rate limits, error handling, or any side effects. The return format is only vaguely described as 'compact comparison'.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

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

  The description is a single sentence in Portuguese, which is concise but lacks structure. It front-loads the key purpose but omits important details. It could be more informative without becoming overly verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (batch API calls, concurrency, multiple parameters, no output schema), the description is insufficient. It does not explain the return format, result handling, or how it differs from related tools. An agent would lack critical context for correct usage.

  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% (urls and concurrency have descriptions), but the description adds no extra meaning beyond the schema. The strategy and categories parameters, which lack schema descriptions, are not elaborated in the description. Thus the description does not compensate for the coverage gap.

  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 analyzes up to 10 URLs using the PageSpeed Insights API v5 with concurrency limits and returns a compact comparison. It effectively distinguishes from siblings like analyze_pagespeed (likely single URL) and compare_web_performance by specifying the batch capability.

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

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to use this tool versus the sibling tools. The description does not explicitly state that it is for batch analysis or that analyze_pagespeed is for single URL. An agent would have to infer from the name, which is unreliable.

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

• compare_web_performanceB
  3.2/5.0
  Behavior2/5

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

  No annotations are present, so the description carries full burden. It mentions combining PSI and CrUX and prioritizing problems, but does not disclose whether it is read-only, authentication needs, rate limits, or other behavioral traits.

  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 a single sentence that front-loads the main action ('Compares multiple URLs'). It is efficient but could be slightly more structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, the combination logic, or the meaning of 'prioritizing biggest problems,' leaving agents underinformed.

  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 25% (only 'urls' has a description). The tool description does not add meaning to individual parameters, only hinting at the combination of PSI and CrUX. It fails to compensate for the low 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 it compares multiple URLs using PageSpeed Insights and CrUX, focusing on Core Web Vitals and lab issues. This verb+resource combination distinguishes it from sibling tools like analyze_pagespeed (single URL) and get_crux_origin (single origin).

  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 implies usage for comparing multiple URLs with combined PSI and CrUX data, but does not explicitly state when to use it versus alternatives, nor does it provide 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.

• get_crux_urlA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It mentions the API call and returned metrics, which is adequate for a simple read operation, but omits details like authentication, rate limits, error handling, or idempotency. The behavior is partially transparent.

  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 sentence that is front-loaded with action and outcome. Every word is necessary, no redundancy.

  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?

  For a simple tool with one parameter and no output schema, the description conveys the core purpose and return values. However, it lacks usage guidelines and behavioral details, leaving some gaps for an agent to fully understand the tool's role and limitations.

  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?

  Input schema has 100% coverage describing the url parameter. The description adds no new meaning beyond 'query CrUX for this URL', which is already in the schema. Baseline of 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 the tool queries the Chrome UX Report API for a specific URL and returns LCP, INP, CLS, and good/needs improvement/poor distributions. This distinguishes it from siblings like get_crux_origin (origin-level) and analyze_pagespeed (different tool).

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

  Usage Guidelines2/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 versus alternatives like get_crux_origin or analyze_pagespeed. The description only states what the tool does without contextualizing appropriate scenarios or exclusions.

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

• get_crux_originA
  3.7/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden of behavioral disclosure. It partially meets this by listing the output metrics but omits important aspects such as whether the tool is read-only, any rate limits, or error handling for invalid origins.

  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, front-loaded sentence that efficiently conveys the tool's purpose and outputs without extraneous words.

  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 simplicity of the tool (one parameter, no output schema), the description adequately explains the return values (LCP, INP, CLS, distributions) and covers the essential information needed for an agent.

  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 schema description coverage at 100%, the baseline is 3. The description does not add meaning beyond the schema's parameter description, merely restating that it queries an origin.

  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 queries the Chrome UX Report API for an origin and enumerates the specific metrics (LCP, INP, CLS) and distributions returned. The verb 'consulta' and resource 'origem' are specific, and the name distinguishes it from sibling 'get_crux_url'.

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

  Usage Guidelines2/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 versus alternatives like analyze_pagespeed or compare_web_performance is provided. The description lacks when-not-to-use or prerequisite information.

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