Server Quality Checklist

Tool Scores

• gsc_search_analyticsC
  2.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds mentioning 'pagination' and 'data freshness controls,' but these are already implied by parameters (row_limit, start_row, data_state). No additional behavioral insights beyond annotations.

  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 of 14 words, front-loading the purpose and key features. No redundancy, but may be too terse given the tool's complexity. Could benefit from slightly more structure.

  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, so description should indicate what the response contains (e.g., rows of data). It fails to explain return values, use cases, or data limitations. Given the tool's 10 parameters and 3 required fields, the description is too sparse.

  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 only 10% (only site_url has a description). While the description vaguely mentions dimensions, filters, pagination, and data freshness, it does not explain individual parameters or their meanings. For a tool with 10 parameters, this is insufficient to help an agent select correct values.

  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 clearly states the tool queries clicks, impressions, CTR, and position from Search Console, listing key features. It distinguishes from siblings by focusing on search analytics querying, but could be more explicit about the resource being 'Google Search Console 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 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 like gsc_compare_periods or gsc_inspect_url. The description does not mention scenarios, prerequisites, or exclusions.

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

• gsc_quick_winsB
  3.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation. The description adds no additional behavioral context beyond what is in the annotations, such as auth needs or rate limits. With annotations covering the safety profile, this score is adequate.

  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 concise (15 words) and front-loaded with the core purpose. However, the extreme brevity sacrifices necessary parameter context. It earns its place but could be slightly expanded to include parameter semantics without becoming verbose.

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

  Completeness1/5

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

  Given the tool's complexity (8 parameters, no output schema, low schema coverage), the description is insufficient. It does not explain how to use the parameters to achieve the stated purpose, leaving the agent unable to construct effective queries. The description should at least briefly clarify the role of key parameters like max_ctr and position ranges.

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

  Parameters1/5

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

  Schema description coverage is only 13%, with only the 'site_url' parameter having a description. The tool description does not explain the meaning or usage of any parameters (e.g., max_ctr, position_min, min_impressions). This leaves the agent without crucial information for correct invocation, especially given the number of parameters.

  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's purpose: identifying queries with meaningful impressions, low CTR, and positions in a target range. It uses a specific verb ('Identify') and resource ('queries'), and the criteria distinguish it from sibling tools like gsc_search_analytics which provide general 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 finding optimizable queries but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites. The agent can infer the use case but lacks clear guidance.

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

• gsc_inspect_urlB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate read-only and idempotent behavior, so the description only adds that it inspects a single URL. No additional details on rate limits, response format, or potential side effects.

  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 of 7 words is highly concise and front-loaded with the key action. However, it may be too brief, sacrificing completeness for brevity.

  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 no output schema and low schema coverage, the description lacks critical details about the return value, how to interpret indexing status, and any required permissions. Sibling tools share domain, but the description does not help the agent decide when to use this tool.

  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 only 33%, and the tool description does not compensate by explaining parameters like language_code or inspection_url. Only the site_url parameter is partially described in 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?

  Description clearly states verb 'inspect', resource 'URL indexing status', and context 'Google Search Console'. It distinguishes from sibling tools like gsc_search_analytics which focus 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 guidance on when to use this tool versus alternatives like gsc_search_analytics or gsc_compare_periods. No exclusions, prerequisites, or usage scenarios provided.

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

• gsc_compare_periodsA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read operation. The description does not contradict these. However, it adds no additional behavioral detail such as how comparison metrics are computed or what 'top rows' means. With strong annotations, the description adds modest value.

  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 11-word sentence with no filler. It is front-loaded with the core action and resource. Every word earns its place.

  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 complexity (8 parameters, no output schema), the description is overly brief. It does not explain what the output looks like, how 'top rows' are determined, or what comparison metrics are provided. Essential behavioral context is missing.

  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 only 13% (only site_url is described). The tool description mentions 'date ranges' and 'dimensions' but does not explain parameters like row_limit, search_type, or the period start/end formats. The description fails to compensate for the low coverage, leaving many parameters unclear.

  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 top rows between two date ranges for the same dimensions. It distinguishes itself from the sibling gsc_search_analytics which likely handles single periods. The verb 'compare' and resource 'top rows' are specific and unambiguous.

  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 two periods, but does not explicitly state when to use this tool versus alternatives like gsc_search_analytics. No exclusion criteria or when-not-to-use guidance is provided. The context is clear but the guidelines are minimal.

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

• gsc_capabilitiesA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds beyond by stating the specific output contents (auth mode, scopes, limits, disclosure notes), providing behavioral context not captured by 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, concise sentence that front-loads the key action and outputs. Every word is meaningful, with no redundant information.

  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 has no parameters, annotations are clear, and the description fully explains the output (auth mode, scopes, limits, disclosure notes), it is complete for its simplicity. No output schema is needed.

  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?

  There are no parameters, so schema coverage is 100% by default. The description compensates by clearly stating what the tool returns, which adds meaning beyond the empty 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?

  The description clearly states the tool returns specific information: active auth mode, scopes, limits, and disclosure notes. It uses specific verbs and resources, and distinguishes from sibling tools that handle search analytics or other functions.

  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 implicitly indicates when to use the tool (when you need server capabilities), but provides no explicit guidance on when not to use or alternatives. Given its simplicity and zero parameters, this is adequate.

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