Server Quality Checklist

Tool Scores

• search_analyticsA
  4/5.0
  Behavior4/5

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

  the readOnlyHint annotation establishes that this is a safe read operation, so the description doesn't need to restate that. The description adds valuable behavioral context by naming the exact return metrics, which is especially important given the absence of an output schema. It doesn't cover details like pagination or rate limits, but the schema already provides rowLimit and date handling.

  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?

  A single, information-dense sentence that front-loads exactly what the tool returns and mentions the key customizability. No filler or redundant restatement of the title or schema.

  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 combination of schema (full parameter documentation), annotation (safe read), and description (returned metrics) covers almost everything an agent needs to call the tool correctly. The only meaningful gap is the lack of explicit usage guidance, but the sibling tool set is distinct enough that confusion is unlikely.

  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%, with each of the six parameters already documented (defaults, formats, enums, required field). The description only says 'dimensions you choose', which adds no information beyond what the schema's dimensions parameter already states, so it doesn't lift the score above the baseline.

  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 ('Returns'), names the exact resource ('Performance report'), and lists the concrete metrics (clicks, impressions, CTR, average position) plus the key option (dimensions). This clearly differentiates it from siblings like list_properties, inspect_url, and list_sitemaps, which target different concerns.

  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 tool's purpose of querying search performance is clear from the title and description, but there is no explicit guidance on when to choose it over alternatives or any stated exclusions. Usage is implied rather than explicitly framed, leaving the agent to infer it is the right tool for search analytics.

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

• diagnose_indexingA
  4.2/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, and the description consistently describes read-only operations. It adds meaningful behavioral context beyond the annotation: it reads from sitemaps, inspects URLs, groups by coverage state, and produces plain-language guidance. No contradiction exists.

  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 with no wasted words. The core purpose is front-loaded, followed by operational detail and then a rationale that aids selection. Every sentence earns its place.

  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, rich parameter schema, and read-only annotation together cover the tool's purpose, input selection, behavior, and output shape at a useful level. An output schema is absent, but the description gives enough return expectation by mentioning grouping by coverage state and guidance. Minor detail about exact response format is not critical for correct invocation.

  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 schema already documents all five parameters. The description reinforces the sitemap-vs-explicit-list behavior for `urls` and `sitemapUrl`, but adds no new parameter meaning beyond what the schema already 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 states a specific action and resource: it 'Explains why pages are or are not indexed' and details the mechanism ('Reads URLs from the site's sitemap', 'inspects each one', 'groups the results by coverage state'). It also distinguishes itself by noting it reconstructs the Pages report not available as a bulk API.

  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 clearly communicates when to use it: for batch index-coverage diagnostics via sitemap or explicit URL list, especially when the Pages report is needed outside the UI. It does not explicitly name sibling alternatives or state exclusions, but the bulk-report framing provides strong usage context.

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

• inspect_urlA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, lowering the bar. The description adds useful behavioral context by specifying exactly what the result includes, such as 'index status', 'canonical Google selected', 'crawl details', and 'mobile usability'. It does not contradict annotations.

  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?

  One tightly written sentence that front-loads the core action and resource ('Returns the full URL Inspection result for one page') and then efficiently lists the included result categories. No wasted 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?

  Since there is no output schema, the description compensates by naming the main result categories an agent should expect. It does not cover error conditions or authentication nuances, but for a read-only inspection tool with only two well-documented parameters, this is reasonably complete.

  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 schema already documents both parameters fully. The description adds no additional parameter-level detail beyond mentioning a single 'page', but the baseline of 3 is appropriate when the schema carries the load.

  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?

  States a specific verb ('Returns'), a specific resource ('URL Inspection result for one page'), and enumerates the result categories (index status, canonical, crawl details, mobile usability, rich results). This clearly distinguishes it from sibling tools like search_analytics or list_sitemaps, which operate on different resources.

  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 clearly implies this is for inspecting a single URL, which gives context for when to use it. It does not explicitly name alternatives or say when not to use it, but the 'one page' scope is sufficient directional guidance.

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

• list_sitemapsA
  4.2/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals a safe read operation, and the description adds useful behavioral context by enumerating the returned information (download time, warnings, errors, per-type counts). No contradiction exists between description and annotations.

  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 sentence that front-loads the action and resource, then lists the returned data compactly. It contains no filler and every clause earns its place.

  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 tool has one required parameter fully covered by the schema, and although there is no output schema, the description enumerates the key return elements. It is sufficient for an agent to understand the tool's purpose and call it 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?

  Schema description coverage is 100%, and the schema already fully documents the siteUrl parameter with format examples. The description adds no additional parameter semantics beyond referring to 'the property', 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 uses a specific verb and resource: 'Shows every sitemap submitted for the property' and details the output fields (last download time, warnings, errors, per-type URL counts). This clearly distinguishes it from siblings like list_properties or inspect_url.

  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 clearly implies when to use the tool: whenever the agent needs submitted sitemaps and their status for a property. It does not explicitly mention when not to use it, but the context is clear enough for correct selection.

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

• list_propertiesA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, and the description reinforces this by saying the properties are those the service account 'can read.' It also adds context about the permission level being included and the purpose of discovering siteUrl strings.

  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. The core action and result are front-loaded, and the usage guidance is compact and directly actionable.

  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, parameterless list tool with no output schema, the description fully covers what the tool returns, its access scope, and how it should be used first. Nothing essential is missing.

  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 zero parameters and schema coverage is 100%, so there is nothing for the description to explain. The baseline of 4 is appropriate for a parameterless tool.

  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?

  States a clear verb ('Lists'), the exact resource ('every Search Console property the configured service account can read'), and the useful detail that it includes permission level. This clearly distinguishes it from sibling tools like diagnose_indexing 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 Guidelines4/5

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

  Provides explicit sequencing guidance: 'Run this first' to discover the siteUrl string needed by other tools. It does not explicitly enumerate alternatives or exclusions, but the intended when-to-use context is unmistakable.

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