Server Quality Checklist

Tool Scores

• gsc_compare_search_periodsA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden for behavioral transparency. It mentions returns improved/declined queries with click/impression changes, sorts by biggest change, and includes a limit. However, it lacks details on statistical significance, pagination, or whether results are aggregated, which would enhance transparency.

  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 well-structured with a header, a bullet for usage, and an Args section. It is clear and front-loaded, with each sentence adding value. Slightly verbose in parameter examples, but overall concise for the level of detail needed.

  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?

  Given 7 parameters, no output schema, and no annotations, the description covers purpose, usage, and parameters well. However, it does not describe the output structure beyond 'returns which queries improved or declined', leaving gaps in understanding the return format.

  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?

  Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for each parameter, including format examples (e.g., site_url format, YYYY-MM-DD for dates), defaults (dimensions, limit), and sources (gsc_list_properties). This adds significant meaning beyond the basic schema titles.

  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 compares search performance between two date ranges and surfaces changes, and explicitly lists use cases (month-over-month, campaign impact, seasonal trends). It distinguishes from sibling tools like gsc_get_performance_overview by focusing on comparative analysis.

  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 explicit usage guidance with 'Use this for:' and lists specific scenarios. However, it does not explicitly state when not to use it or contrast with alternatives like gsc_get_performance_overview, which could further improve clarity.

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

• gsc_get_sitemapsA
  4.3/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Describes output (status, error counts, indexed URLs) but does not disclose behavioral traits like error handling, rate limits, or prerequisites beyond property format.

  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 and a bullet list, front-loaded with purpose and use cases. Every line provides value.

  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?

  Single parameter is well-documented. Output is described in the first sentence. Lacks explicit return format or error info, but sufficient for a list tool.

  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?

  Schema has 0% description coverage, but description explains the site_url parameter format and source (from gsc_list_properties). Provides crucial context beyond the schema.

  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?

  Clearly states the tool lists all sitemaps for a GSC property with submission status, error/warning counts, and indexed URL totals. Distinguishes from sibling tools like gsc_compare_search_periods and gsc_get_performance_overview.

  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?

  Explicitly lists use cases (monitoring crawl health, finding sitemap errors, etc.). Does not explicitly mention when not to use or alternatives, but the use cases are clear.

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

• list_accessible_customersA
  4.7/5.0
  Behavior5/5

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

  Discloses output format (resource names like 'customers/1234567890') and instructs to extract numeric ID for other tools. No annotations provided, so description carries full burden and does it well.

  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, front-loaded with 'Start here', no wasted 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?

  Covers purpose, usage order, output format, and integration with other tools. No gaps given zero parameters and existence of output schema.

  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?

  No parameters; baseline score of 4 as description adds no param info (none needed).

  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?

  Clear verb 'list' + resource 'accessible customers'; distinguishes itself from search() by stating 'Always call this first before search()'.

  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?

  Explicitly states when to call ('Start here', 'Always call this first before search()'), but does not mention when not to use or alternatives.

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

• get_resource_metadataA
  4.8/5.0
  Behavior4/5

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

  No annotations provided, but description fully explains input, output structure with example, and includes compatible fields. No side effects noted, which is appropriate for a read-only discovery tool.

  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?

  Front-loaded with purpose and usage, followed by structured Args and Returns sections. Every sentence adds value with no 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 simple one-parameter tool with no annotations or output schema, the description provides complete context: purpose, usage, parameter explanation, return format, and examples.

  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?

  Schema coverage is 0%, but description compensates with detailed explanation of the single parameter 'resource_name', including example values and a list of common resources.

  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 the tool discovers which fields are SELECTable, FILTERable, and SORTable for a Google Ads resource, with explicit examples. It distinguishes itself from siblings like 'search' by being a preparatory tool.

  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?

  Explicitly advises 'Always call this before search()' and explains that using incorrect field names causes API errors, providing clear when-to-use guidance.

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

• gsc_get_performance_overviewA
  4.8/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries full burden. It describes output as totals and daily breakdown, and implies a read-only operation. It does not mention auth or error handling, but given the simplicity, it is adequately 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?

  Two concise paragraphs: first clearly states purpose and usage, second documents parameters. Every sentence adds value, and information is front-loaded.

  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 fully explains return values (totals and daily breakdown). Also mentions dependency on gsc_list_properties for obtaining the site_url. No gaps for the tool's scope.

  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?

  Schema description coverage is 0%, so description must compensate. It explains site_url format precisely, referencing gsc_list_properties, and notes the default for days. Both parameters are well-described.

  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 provides an executive summary with daily trends for clicks, impressions, CTR, and average position, plus a day-by-day breakdown. It distinguishes itself from the sibling tool gsc_get_search_analytics by noting that the latter is for detailed query-level 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?

  Explicitly states when to use: quick snapshots, dashboards, spotting traffic spikes or drops. Also provides a clear alternative: for detailed query-level data, use gsc_get_search_analytics.

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

• searchA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full burden and does an excellent job. It declares read-only nature, auto-routing for manager accounts, annotation of results with source fields, field formatting rules (e.g., fully-qualified names, date formats), and behavior for conditions, ordering, and limits.

  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 well-structured into sections: summary, workflow, field rules, common conditions, example, and Args. Every sentence is informative and there is no redundancy. It is detailed yet concise, earning 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?

  Given the tool's complexity (6 parameters, no annotations, but output schema exists), the description covers all essential aspects: purpose, parameters, behavior, edge cases (MCC routing), examples, and field rules. It is comprehensive and leaves no important gaps.

  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?

  Schema description coverage is 0%, but the description adds detailed meaning for each parameter in the Args section: customer_id as numeric with MCC auto-detection, resource name, fully-qualified fields, AND-combined conditions, ordering format, and limit defaults. This fully compensates for the lack of 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 that the tool executes a read-only GAQL query and returns flattened results. It distinguishes itself from sibling tools like get_resource_metadata and list_accessible_customers by focusing on query execution, with a specific workflow mentioned.

  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 includes a workflow (list_accessible_customers() → get_resource_metadata(resource) → search()) that implies when to use this tool. It also provides context about manager account routing and field rules. However, it does not explicitly state when not to use it or compare directly with siblings.

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