Server Quality Checklist

Tool Scores

• search_analyticsA
  3.5/5.0
  Behavior2/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 mentions the data_state parameter for data freshness but does not disclose rate limits, authorization requirements, error handling, or side effects. The return format is described minimally.

  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 well-structured docstring with a brief overview and parameter list. It is efficient but could be slightly more concise by integrating parameter descriptions into a narrative. However, it remains clear and organized.

  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?

  With 9 parameters, no output schema, and no annotations, the description covers parameter semantics and basic return shape. It mentions pagination via start_row but lacks information on error behavior, rate limits, or field-level output details. Adequate but incomplete.

  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?

  The input schema has 0% description coverage, but the tool's description provides detailed explanations for each parameter, including examples (e.g., site_url formats), allowed values (dimensions, search_type), and default behaviors. This fully compensates for the schema 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 it queries Search Console search-performance data (the Performance report), with a specific verb and resource. It distinguishes from sibling tools (get_sitemap, inspect_url, etc.) by focusing on analytics data.

  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, nor any when-not-to-use conditions. The description implies usage for performance data but lacks context on prerequisites or exclusions.

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

• list_sitemapsA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, and the description omits behavioral traits such as read-only nature, permission requirements, rate limits, or pagination. The agent lacks critical information about the tool's 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?

  The description is short and front-loaded with the main action. The 'Args:' section is somewhat redundant given the schema, but overall it remains concise and focused.

  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?

  While the tool is simple with one parameter, the description does not specify the return format, pagination, or any limits. With no output schema, the agent lacks complete information to handle the response.

  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 description adds value by explaining the site_url parameter with an example (sc-domain:example.com), supplementing the sparse schema where schema description coverage is 0%. This clarifies the expected input format.

  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 sitemaps for a property, with a specific verb and resource. It is distinct from sibling tools like get_sitemap, which likely retrieves details of a single sitemap.

  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 provides an example of the site_url format but does not specify when to use this tool versus alternatives like get_sitemap or inspect_url. Usage context is implied but not explicit.

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

• list_sitesA
  3.9/5.0
  Behavior4/5

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

  Despite no annotations, the description discloses that the tool returns each site's URL and permission level. It does not mention pagination or rate limits, but for a simple list with no parameters, this is sufficient.

  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 sentences with no filler. First sentence front-loads the purpose, second provides additional return details. Every word earns its place.

  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 parameterless tool with no output schema, the description is complete. It specifies the output (URL and permission level) and the scope (authenticated account's accessible properties).

  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?

  No parameters exist, so schema description coverage is 100%. Baseline score of 3 applies; description does not need to add parameter details.

  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 states it lists Search Console properties the authenticated account can access, with specific verb 'Lists' and resource 'Search Console properties'. Distinguishes from sibling tools that deal with sitemaps, URLs, or analytics.

  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. For example, it does not recommend using it before other tools like search_analytics to obtain site URLs.

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

• get_sitemapA
  4/5.0
  Behavior3/5

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

  No annotations are provided. The description discloses that it returns 'index status and errors' but does not mention side effects (likely none), permissions, or rate limits. It provides moderate transparency for a read operation.

  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 very concise: a single purpose sentence followed by parameter documentation. Every sentence adds value, and the structure is front-loaded. No 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?

  The description is largely complete for a simple getter tool with two parameters and no output schema. It explains what is returned and provides parameter examples. It does not cover error scenarios or permissions, but given the tool's simplicity, it is nearly complete.

  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 0%, but the description adds meaningful details: site_url example 'sc-domain:example.com' and feedpath example 'https://example.com/sitemap.xml'. This clarifies the expected format and adds value beyond the schema's property names.

  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 'Returns details for a single sitemap, including index status and errors.' The verb 'Returns' and resource 'single sitemap' are specific. It distinguishes from the sibling list_sitemaps which lists multiple sitemaps.

  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?

  Usage context is implied but not explicitly stated. The description assumes the user has a specific sitemap URL. No guidance on when to use this tool versus alternatives like inspect_url or list_sitemaps, nor any prerequisites or exclusions.

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

• inspect_urlA
  4.1/5.0
  Behavior4/5

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

  No annotations provided, so description discloses read-only nature, reports various data, and tight per-property quotas. It does not cover error handling or rate limits explicitly, but the quota warning adds useful transparency.

  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?

  Description is front-loaded with purpose, followed by reported data, a quota note, and parameter definitions. Every sentence serves a purpose without 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?

  Despite no output schema, description covers main behavioral aspects and parameter details. However, it lacks information on return format, error scenarios, or interpretation of results, limiting completeness for a 3-param 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?

  With 0% schema coverage, description adds value by providing an example for site_url, describing inspection_url as fully-qualified, and noting language_code default. This goes beyond schema's basic type info.

  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 inspects a URL's index status via the URL Inspection API, listing specific data points (index coverage, last crawl, etc.). It is distinct from sibling tools like get_sitemap or search_analytics.

  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 checking a single URL's status but does not explicitly compare to siblings or state when not to use it. The quota mention provides context, but guidance is indirect.

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