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

Beyond the annotations (read-only, idempotent, non-destructive), the description discloses two meaningful behavioral traits: concurrency limiting ('bounded concurrency') and per-URL error handling ('partial failures are returned per URL'). This adds value without contradicting the annotations.

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

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

The description is a single, front-loaded sentence that conveys the core action and key operational behavior. Every word contributes meaning without unnecessary verbosity.

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

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

Given the tool's moderate complexity (4 parameters, no output schema) and low schema coverage, the description is too sparse. It does not explain what the inspection results look like, the maximum URL count, the meaning of 'partial failures', or any usage prerequisites. The mention of partial failures is helpful but incomplete without clarifying the response structure.

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

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

Schema description coverage is only 25% (only siteUrl has an inline description). The tool description provides no parameter-level detail about concurrency limits, languageCode, or inspectionUrls format. It only alludes to 'multiple URLs', which overlaps with inspectionUrls. With low schema coverage, the description fails to compensate for the missing parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Inspect multiple URLs' with a specific distinctive feature ('bounded concurrency'). It distinguishes itself from the sibling gsc_inspect_url by explicitly targeting multiple URLs rather than a single one.

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

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

The description implies a batch use case ('multiple URLs') but does not explicitly contrast with alternatives like gsc_inspect_url for single-URL inspection. It mentions bounded concurrency and partial failures, which hint at operational context, but lacks clear 'when to use / 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.

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds a useful behavioral detail: it can use an explicit previous range or fall back to the immediately preceding equal-length period. This adds some context beyond the annotations.

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

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

The description is a single, concise sentence with no filler. Every word contributes to understanding the tool's purpose, and the key distinction (explicit vs. preceding equal-length) is front-loaded.

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

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

The tool has 11 parameters and no output schema, yet the description doesn't mention what the output looks like, how the comparison results are structured, or what dimensions/aggregations are applicable. It is too sparse for a tool of this complexity.

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

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

The description clarifies the core date parameters: 'current' and 'previous' ranges, specifying that if no previous range is given, it defaults to the equal-length preceding period. However, with schema description coverage at only 9%, the description should explain more of the 11 parameters, such as dimensions, filters, or type, but does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: comparing a date range with either an explicit previous range or the preceding equal-length period. It uses a specific verb ('compare') and a resource ('date range'), and distinguishes itself from sibling query tools that focus on single-period data.

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

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

No explicit guidance is provided on when to use this tool versus alternatives like gsc_diagnose_traffic_drop or gsc_detect_content_decay. The description states what it does but gives no context for selecting it over other tools.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds value by stating the output is a 'review signal, not proof,' which is a useful interpretive nuance. It does not mention behavioral thresholds like minimumPages or minimumImpressions that affect results, but given the strong annotations, the additional context 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.

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

The description is a single, front-loaded sentence with no redundant phrasing. Every clause adds meaning: the resource ('queries receiving impressions or clicks from multiple pages'), the temporal scope ('in the same period'), and the interpretive caveat ('review signal, not proof'). It is exemplary in conciseness.

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

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

The tool has 11 parameters, three required, and no output schema, yet the description only covers the core purpose. It lacks guidance on parameter usage, output interpretation, or example scenarios. For a complex analytical tool, this description is minimally adequate but leaves gaps for proper invocation and result understanding.

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

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

Schema description coverage is only 9% (only siteUrl has a description), meaning 10 parameters are completely undocumented. The description provides no parameter semantics, failing to explain filters, dimensions, minimumPages, minimumImpressions, dataState, aggregationType, or maxRows. With such low coverage, the description needed to compensate but did not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Find' with a detailed resource: 'queries receiving impressions or clicks from multiple pages in the same period.' It immediately distinguishes this tool from sibling query tools by focusing on cannibalization detection. The caveat 'this is a review signal, not proof' further clarifies its purpose and limits.

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

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

The description implies usage for reviewing potential keyword cannibalization and sets expectations that results should be treated as signals, not definitive proof. However, it does not explicitly name alternatives or state when not to use this tool relative to siblings like gsc_query_queries or gsc_diagnose_traffic_drop. The guidance is more interpretive than directional.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, so safety is covered. The description adds that it compares two periods and focuses on declining metrics, but it does not disclose how decline is computed, whether both periods are user-defined, or what the output structure is. Minimal extra behavioral context is provided.

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

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

The description is a single, efficient sentence that front-loads the core purpose. While it is concise, it omits necessary detail, but for the purpose it serves, the brevity is acceptable.

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

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

With 9 parameters and no output schema, the description is far too minimal. It does not clarify required inputs, how periods are formatted, what 'declining' means, or what results look like. This is insufficient for a tool of this complexity, despite annotations covering safety.

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

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

Schema description coverage is only 11% (only siteUrl has a description). The description only vaguely references 'two periods' and does not explain key parameters like currentStartDate, previousStartDate, type, maxRows, or minimumPreviousClicks. 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: finding pages with declining clicks and impressions between two periods. It uses a specific verb and resource, and the focus on declining metrics differentiates it from generic analytics tools, though it does not explicitly name sibling alternatives.

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

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

The description implies a use case (identifying content decay) but does not provide explicit guidance on when to choose this tool over siblings like gsc_compare_periods or gsc_diagnose_traffic_drop. No exclusions or alternative recommendations are given.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description adds a valuable behavioral note that results are 'evidence, not causal attribution,' which helps set expectations about the output's interpretative nature. This goes beyond what annotations provide, though it doesn't cover other traits like pagination or rate limits.

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

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

The description is two short sentences. The first sentence front-loads the primary purpose, and the second adds a necessary caveat. It is concise, clear, and without filler.

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

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

There is no output schema, so the description should partially explain what to expect. It mentions result categories (pages, queries, countries, devices) but does not describe the output format, pagination, or how results are sorted. The 'evidence not causal' note adds context but overall the description leaves moderate gaps for a tool with 8 parameters and no output schema.

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

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

Schema description coverage is only 13%, leaving most parameters without explanatory text. The description does not elaborate on any parameters (e.g., date ranges, type, dataState). It only implies 'period-over-period' through the concept, but does not map to the specific date parameters. The description 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: finding pages, queries, countries, and devices with the largest period-over-period traffic declines. It uses a specific verb ('Find') and resource scope, distinguishing it from sibling tools like gsc_query_pages or gsc_compare_periods.

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

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

The description implies a clear usage context: diagnosing traffic drops by identifying declining dimensions. The caveat 'Results are evidence, not causal attribution' provides important context about how to interpret results. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral details beyond the filtering criteria, but it also does not contradict the annotations and provides sufficient context for a read-only analytic tool.

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

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

The description is a single, well-structured sentence with no filler. It front-loads the primary action and target criteria, making it easy to parse and act upon.

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

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

Given the tool's complexity (12 parameters, no output schema), the one-sentence description is somewhat thin. It explains the core purpose but does not convey what a returned opportunity set looks like, how thresholds interact, or when results might be empty. The rich schema and annotations help, but the description alone is not fully complete for an agent to anticipate behavior.

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

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

Schema description coverage is only 8%, so the description must compensate. It does clarify the core semantic parameters: 'high-impression' maps to minimumImpressions, 'low-CTR' to maximumCtr/targetCtr, and 'ranking-position range' to minimumPosition/maximumPosition. However, it does not explain other important parameters like groupBy, filters, limit, or date range, leaving gaps for a 12-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Find' and clearly identifies the resource: high-impression, low-CTR queries or pages within a ranking-position range. This distinguishes it from sibling tools like gsc_query_queries or gsc_top_pages by focusing on opportunity detection rather than generic reporting.

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

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

The description conveys a clear use case: discovering optimization opportunities (high impressions but low CTR) within a specified position band. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to select this over generic query/page tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds minimal context by naming 'access level details' but doesn't disclose response format or potential errors.

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

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

Single sentence, front-loaded with the verb, and contains no filler. Every word earns its place.

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

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

With one well-documented parameter and strong annotations, the description is mostly sufficient. However, since no output schema exists, it could briefly mention what 'access level details' includes to fully prepare the agent.

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

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

Schema description covers siteUrl with examples at 100% coverage. The description adds no new parameter semantics beyond emphasizing 'one property', which is already implied by the parameter name and schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Get' with resource 'access level details' and scope 'one Search Console property', clearly distinguishing it from sibling tools like gsc_list_sites or gsc_get_sitemap.

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

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

No explicit usage guidance or alternatives are mentioned. The phrase 'for one Search Console property' implies targeted use, but it does not state when to choose this over list or other sibling tools.

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

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

Annotations already provide read-only, idempotent, and non-destructive hints. The description adds no extra behavioral context such as error handling, authentication needs, or rate limits. It is consistent with annotations but adds little beyond them.

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

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

The description is a single concise sentence that is direct and free of redundant wording. It efficiently communicates the tool's primary purpose.

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

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

For a simple retrieval tool, the description covers the basic purpose and is consistent with annotations, but it lacks details on what 'details' includes and provides no explanation of the feedpath parameter. Given the absence of an output schema and the schema's partial coverage, some additional context would improve completeness.

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

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

The schema describes siteUrl but not feedpath (50% coverage), and the description does not clarify either parameter. The meaning of feedpath remains ambiguous, and the description fails to compensate for the schema's gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get details'), the resource ('one submitted sitemap'), and the scope, distinguishing it from sibling tools like gsc_list_sitemaps which lists sitemaps. It is a precise and unambiguous statement.

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

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

The description implies use for retrieving a single sitemap's details but does not explicitly state when to choose this tool over alternatives, nor does it mention any exclusions or usage context. The distinction from listing tools is implied but not named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by clarifying that the tool returns Google's indexed version, not a live test, which goes beyond the annotations.

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

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

The description is very concise: two short sentences that immediately state the tool's purpose and a key limitation. Every word earns its place, with no extraneous content.

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

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

The tool is simple, and the description covers its core purpose and non-live nature. However, it lacks guidance on when to use this vs. alternatives, does not elaborate on parameters, and provides no information about the response format. Annotations mitigate some gaps, but completeness is minimal.

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

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

The description does not explain any parameters. The input schema describes only siteUrl (33% coverage), leaving languageCode and inspectionUrl without descriptions. Since schema coverage is low and the description fails to compensate, parameter semantics are weak.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Inspect' and resource 'Google's indexed version of a URL', clearly indicating what the tool does. It distinguishes from a live URL test, though it does not differentiate from the sibling tool gsc_bulk_inspect_urls, which is a related alternative.

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

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

The statement 'This is not a live URL test' provides a negative usage hint, telling users when not to use the tool. However, it does not explicitly state when to use this tool or mention alternatives like gsc_bulk_inspect_urls, leaving usage context implied rather than explicit.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds minimal context ('submitted') but does not disclose pagination, limits, or the meaning of the sitemapIndex parameter. Overall, it provides some value beyond annotations but is not rich.

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

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

The description is a single, clear, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's function.

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

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

While the tool is simple and annotations provide safety context, the description is minimal. There is no output schema, so the agent cannot anticipate the response structure. The optional sitemapIndex parameter is not explained, and the description does not clarify whether the result includes sitemap index children or other details. It is adequate but has clear gaps.

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

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

Schema description coverage is 50%: siteUrl is documented in the schema, but sitemapIndex is not. The tool description does not describe any parameters or clarify the purpose of sitemapIndex, leaving the agent without meaningful additional context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('sitemaps') with a clear scope ('for a Search Console property'). It distinguishes itself from siblings like 'gsc_get_sitemap' (singular) and query tools by focusing on listing submitted sitemaps.

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

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 alternatives like gsc_get_sitemap or query tools. There is no mention of exclusions, prerequisites, or scenarios where a different tool would be more appropriate.

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

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

Annotations already declare the tool read-only, open-world, idempotent, and non-destructive. The description adds the scoping behavior that only properties available to the authenticated account are returned, which is useful context. However, it does not disclose other behaviors like return format or pagination, so it adds limited value beyond the annotations.

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

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

The description is a single, focused sentence that is front-loaded with the main action. It contains no filler or redundant information, making it highly concise and well-structured.

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

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

For a simple list tool with no output schema and strong annotations, the description is complete. It clearly states the purpose and scope, and the annotations cover the safety profile. No additional details are necessary for effective use.

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

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

The tool has zero parameters, so the parameter schema already covers everything. The description doesn't need to explain parameters, and the baseline of 4 applies for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('Search Console properties'), with a clear scope ('available to the authenticated Google account'). It clearly distinguishes from sibling tools like gsc_get_site (which retrieves a single property) and gsc_list_sitemaps (which lists sitemaps).

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

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

The description clearly states it lists properties accessible to the authenticated account, giving the context that this is the tool for enumerating available properties. It doesn't explicitly mention alternatives or exclusions, but the use case is obvious from the context.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the grouping dimension ('by country') but does not disclose any other behavioral details such as response format, pagination, or interaction with filters. This adds some context but is not rich.

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

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

The description is a single, direct sentence that immediately communicates the tool's core function. There is no wasted wording, and it is appropriately front-loaded with the action and resource.

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

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 a low schema description coverage, the description is far too minimal to provide complete context. It does not explain the return format, how grouping is implemented (e.g., via dimensions), or how to set date ranges. This would be inadequate for an agent to use effectively without additional inference.

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

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

Schema description coverage is only 11% (only siteUrl has a description). The description text does not explain any parameters, such as dimensions, filters, or aggregationType. It does not compensate for the lack of schema descriptions, leaving the agent without meaningful parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Query') on a specific resource ('Search Analytics') with a specific grouping dimension ('by country'). This distinguishes it from siblings like gsc_query_pages and gsc_query_queries.

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

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

The description implies usage for country-level search analytics data but provides no explicit guidance on when to choose this tool over alternatives such as gsc_query_queries or gsc_query_devices. The name and grouping hint are present, but no direct comparisons or exclusions are mentioned.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side effects. The description adds no additional behavioral context such as pagination, date-range constraints, or how the grouping affects results. It only restates what is evident from the tool name.

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

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

The description is a single, concise sentence free of unnecessary words. It front-loads the core purpose efficiently with no fluff, making it highly scannable for an agent.

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

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

Given the tool has 9 parameters, no output schema, and a minimal description, the agent has insufficient context to understand return formats, how to properly set dimensions, or how this tool relates to the broader Search Analytics suite. The description is far too sparse for the tool's complexity.

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

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

Schema description coverage is very low (11%), with only siteUrl described. The description mentions 'device' but does not explain how to configure the dimensions parameter or any other parameters. It fails to compensate for the lack of schema descriptions, leaving most parameters underspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Query Search Analytics grouped by device' clearly states the action (query), the resource (Search Analytics), and the specific grouping (device). It distinguishes this tool from siblings such as gsc_query_queries, gsc_query_pages, and gsc_query_countries by specifying the device dimension.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or mention sibling tools. The usage is only implied by the tool name and description.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the 'grouped by page' behavior but does not disclose further details like pagination, rate limits, or default aggregation. 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.

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

The description is a single, front-loaded sentence with no filler or redundancy. It is concise and well-structured, though the brevity may underrepresent the tool's complexity.

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

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

The tool is complex with 9 parameters, filters, and multiple dimensions, yet the description only states 'grouped by page'. With no output schema, the description should provide more context about return values, default behavior, or constraints, but it does not.

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

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

Schema description coverage is extremely low (only 11%), and the tool description provides zero information about parameters. It fails to explain startDate, endDate, maxRows, filters, dimensions, or aggregationType, leaving the agent without meaningful semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool queries Search Analytics grouped by page, using a specific verb and resource. This directly differentiates it from sibling tools like gsc_query_queries (grouped by query) and gsc_query_countries.

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

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

No guidance is provided on when to use this tool versus alternatives such as gsc_query_queries or gsc_query_devices. The description does not mention selection criteria or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the grouping behavior, which is useful, but it does not disclose pagination, maxRows limits, dataState variations, or return format. This provides minimal extra behavioral context beyond the annotations.

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

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

The description is a single, tightly written sentence with no redundant or filler content. It is front-loaded with the action and resource, making it immediately scannable.

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

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 the presence of many sibling tools, this one-sentence description is insufficient. It doesn't mention typical response metrics, filter capabilities, row limits, or usage scenarios. The schema provides defaults and enums but not semantic meaning, so the tool is only minimally contextualized.

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

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

Schema description coverage is only 11% (only siteUrl is described). The description does not explain filters, date format, maxRows, dimensions, or aggregationType. It only implies 'query' as the grouping dimension, aligning with the schema default, so 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Query Search Analytics grouped by search query' clearly states the verb (query), resource (Search Analytics), and the grouping dimension (search query). This effectively distinguishes it from sibling tools like gsc_query_pages and gsc_query_countries, though 'query' as a verb is slightly generic.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as gsc_search_analytics, gsc_top_queries, or gsc_query_pages. Usage must be inferred from the tool name and siblings, with no exclusions or context given.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and behavioral aspects. However, the description adds no extra context beyond the grouping dimension, such as pagination, rate limits, or default date ranges. It does not contradict annotations, but provides minimal additional behavioral transparency.

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

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

The description is a single, clear sentence without unnecessary words, making it concise and easily parsed. It loses a point for being overly minimal—while concise, it could include a bit more operational detail without becoming verbose.

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

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

Given the tool has 9 parameters, 3 required, and no output schema, the description is insufficiently complete. It does not explain how to set the grouping dimension, date formats, site URL requirements, or what the response contains, leaving an AI agent without enough context to invoke the tool correctly.

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

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

With only 11% schema description coverage, the description must compensate for parameter meaning, but it only mentions 'grouped by search appearance,' hinting at the dimensions parameter. It does not explain required parameters like siteUrl, startDate, endDate, or optional ones like filters, maxRows, or aggregationType, leaving significant gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Query Search Analytics grouped by search appearance' uses a specific verb and resource, clearly identifying the tool's purpose and distinguishing it from sibling tools like gsc_query_queries and gsc_query_pages. The grouping dimension 'search appearance' is mentioned explicitly, making the tool's function unambiguous.

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

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

The description implies use for search appearance grouping, but does not explicitly state when to use this tool versus alternatives or provide exclusions. There is no cross-reference to sibling tools, leaving the usage context only implied by the naming convention.

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

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 safety profile is covered. The description adds the capability of 'optional dimensions and filters' but does not disclose any deeper behavioral details such as data freshness, pagination, result structure, or API limits. This is acceptable given the annotations but adds minimal extra transparency.

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

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

The description is a single concise sentence with the core function front-loaded: 'Query clicks, impressions, CTR, and average position.' It avoids unnecessary words and is easy to scan, making it highly efficient.

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

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

For a tool with 9 parameters, no output schema, and numerous sibling tools, the description is incomplete. It does not mention the required parameters (siteUrl, startDate, endDate), clarify return values beyond listing metrics, or explain how this generic tool relates to the specialized siblings. The low schema coverage and lack of output schema increase the burden, which the description fails to meet.

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

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

Schema description coverage is only 11% (only siteUrl has a description), so the description must compensate for the other 8 parameters. It mentions 'dimensions and filters' generically but fails to explain parameters like type, dataState, maxRows, aggregationType, or how to choose dimension values. The schema's enums help but do not clarify the semantics of each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool queries Search Console metrics (clicks, impressions, CTR, position) with optional dimensions and filters. It is specific enough to convey the core purpose, though it does not explicitly distinguish itself from sibling tools like gsc_query_pages or gsc_query_queries, which are narrower variants.

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

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

There is no guidance on when to use this generic analytics query versus the specialized sibling tools (e.g., gsc_query_pages, gsc_query_queries). The description does not mention comparison to alternatives, prerequisites, or typical use cases, leaving the selection decision to the agent.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context by noting it runs locally and makes no external calls, which is not apparent from annotations alone.

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

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

The description is a single, densely informative sentence. Every phrase—server version, authentication guidance, safety information, without calling Google—adds distinct value with no redundancy.

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

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

For a parameterless info tool with no output schema, the description adequately covers the tool's purpose and key behavioral caveat. However, 'safety information' is somewhat vague, leaving room for interpretation about what exactly is returned.

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

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

The tool has zero parameters and an empty schema, so parameter semantics are trivially covered. The description adds meaning by specifying the nature of the returned information, meeting the baseline for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: returning local server version, authentication guidance, and safety information. It explicitly notes 'without calling Google', which distinguishes it from sibling tools that all interact with Google Search Console data.

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

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

The description implies when to use this tool: when local server/environment information is needed rather than Google data. It does not explicitly name alternatives or exclusions, but given the sibling list, the use case is evident.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds that results are ordered by highest clicks, but does not disclose that the default dimensions setting is 'query', which may return queries rather than pages unless overridden—a potential mismatch with the tool's name.

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

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

The description is a single sentence that directly conveys the core functionality with no filler words. It is well-structured and immediately understandable.

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

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

For a tool with 10 parameters, no output schema, and minimal schema descriptions, this description is inadequate. It omits any mention of pagination, default limits, dimension handling, or how the results are returned. The simple sentence does not provide enough context for an agent to use the tool effectively, especially given the lack of schema guidance.

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

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

Schema description coverage is only 10% (only siteUrl has a description). The description does not explain any parameters, such as limit, dimensions, filters, or dataState. Since schema coverage is low, the description should compensate, but it remains silent on parameter meaning or defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Return'), the resource ('highest-clicked pages'), and the scope ('for a date range'). It distinguishes from gsc_top_queries which focuses on queries, but does not explicitly differentiate from gsc_query_pages, which also returns pages.

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

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

Provides no guidance on when to use this tool versus alternatives like gsc_query_pages or gsc_top_queries. No prerequisites, exclusions, or context for choosing this tool are mentioned.

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

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 read operation. The description adds value by noting it returns the highest-clicked queries for a date range, but it does not disclose pagination, response format, or default limits beyond what the schema implies.

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

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

The description is a single, front-loaded sentence that contains no filler or repetition. Every word earns its place, making it highly concise.

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

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

With 10 parameters, no output schema, and many sibling tools, this description is far too vague. It does not explain the return structure, how to filter results, or how 'top' is determined beyond clicks, leaving the agent with significant gaps for correct invocation.

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

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

Schema description coverage is only 10% (siteUrl has a description). The description compensates for startDate/endDate and the concept of top queries, but it fails to explain key parameters like filters, dimensions, dataState, aggregationType, limit, and maxRows, which are critical for correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns search queries sorted by clicks for a date range, using a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like gsc_query_queries or gsc_search_analytics, though the 'highest-clicked' phrasing implies a ranking.

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

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

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites. It merely states what it does, leaving the agent to infer usage from the name and description.

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