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

With annotations already declaring readOnlyHint, idempotentHint, and destructiveHint, the description adds valuable detail about the comparison logic and the types of movements detected (lost positions, collapsed CTR, dropped/vanished pages). It explains that only movements past alerting rules are returned, which is behavior beyond the schema. No contradiction with 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 two sentences long and front-loads the purpose with a question-like hook. The second sentence explains mechanics efficiently. The first sentence is a bit vague, but overall it is compact and free of fluff.

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 description covers the core algorithm and output filtering, and an output schema exists so return format is not required here. It does not mention usage context or alternatives, which is a minor completeness gap for a complex alerting tool, but it is sufficient for basic 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 86%, so most parameters are already documented in the schema. The description adds no new meaning about parameter format or semantics; it only mentions window_days implicitly via the comparison logic. This meets the baseline for high 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 compares two windows and returns only movements that pass alerting rules, which is a specific and concrete purpose. It mentions both queries and pages, distinguishing it from tools focused only on one. However, it does not explicitly differentiate itself from siblings like gsc_traffic_drops or gsc_compare_periods, leaving some ambiguity.

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. It does not mention exclusions, prerequisites, or recommended contexts beyond a vague 'today' cue. This is a gap, especially given the large set of 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?

The annotations already establish read-only, idempotent behavior. The description adds meaningful context beyond that: adaptive thresholds for small sites, English/Italian availability, the instruction to ask for a period, and the two-stage return of a compact JSON summary followed by the report path/document. This gives the agent a clear picture of what to expect 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?

Every sentence earns its place: scope, contents, adaptive behavior, language, user-interaction guidance, and return format. The description is dense but not bloated, and the most important identifying sentence is first. No filler or repetition of schema details.

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 complex 13-parameter tool with no output schema, the description is remarkably complete. It explains the report scope, the adaptive thresholds, the language options, the critical 'ask about period' behavior, and the JSON-first return strategy. Combined with the fully described schema and safety annotations, an agent has enough context to invoke it 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?

Schema description coverage is 100%, so the schema carries the parameter definitions. The description adds value beyond the schema by explaining why the default period is often wrong, that thresholds adapt to property size, and that output can be a summary plus report. This helps the agent make better parameter choices, especially around `period` and `language`.

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 opens with a specific verb and resource: 'Build a complete, self-contained HTML SEO audit for one property.' It then enumerates the major components (top queries, pages, devices, countries, sitemaps, indexing, strategy, roadmap), making the tool's scope unmistakable and clearly broader than the focused sibling tools like gsc_query or gsc_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?

It provides explicit operational guidance: 'Ask the user for the period if they have not named one,' including why the 28-day default is inadequate for client reports. It does not directly name alternatives or state when not to use this tool, but the comprehensive scope makes its role as the full-audit tool clear.

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?

Beyond the readOnly/idempotent annotations, the description discloses a real operational limitation: only one page of up to 25,000 query/page pairs is read, the tail is cut off on large properties, and a meta field reports how many pairs were analyzed. This is valuable context that an agent cannot derive from annotations or the schema.

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 three short sentences with the core purpose front-loaded, followed by the scale caveat and output layout. There is no filler or repetition.

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 read-only annotations, high schema coverage, and an output schema, the description covers the key operational caveats: page limit, tail cutoff, and meta reporting. It is complete enough for an agent to call and interpret this 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?

Schema description coverage is 91%, so the schema already documents nearly all parameters. The description adds no parameter-specific detail beyond saying rows list competing pages with clicks and positions, which is more about the output than the parameters; the baseline 3 applies.

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 identifies the subject: queries where several pages compete for the same result, and the title reinforces the concept of keyword cannibalisation. It is specific enough to know what the tool returns, though it lacks an explicit verb and does not name a sibling to distinguish itself.

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 siblings such as gsc_query, gsc_quick_wins, or gsc_content_decay. The topic is implied but there are no conditions, exclusions, or alternatives stated.

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 and idempotentHint. The description adds valuable behavioral detail: rows missing from one period are kept with zeros, movers are returned worst-first, and meta reports gained versus lost click counts. This goes well beyond the annotation hints.

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 compact and front-loaded: the first sentence states the core operation, and each subsequent sentence adds a distinct, necessary behavioral detail. There is no filler and no repetition of schema 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?

Given the rich input schema, output schema, and annotations, the description still covers the non-obvious behaviors an agent needs: one-sided rows are retained with zeros, ordering is worst-first, and meta counts gains versus losses. Nothing essential for correct invocation is missing.

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 100% and every parameter already has its own useful description, so the baseline of 3 applies. The description reinforces the period-comparison concept but does not add parameter syntax or date semantics 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 opening sentence names a specific operation: joining two periods on a dimension and ranking rows by click delta. Framing it as the 'what changed' comparison tool distinguishes it from more specific sibling trend tools like gsc_traffic_drops and gsc_content_decay.

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 gives a clear use case: answer 'what changed' between periods without manually diffing tables. It does not explicitly name sibling alternatives or exclusion criteria, but the context is clear and not misleading.

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 establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds useful operational context: 'One query per month runs in parallel,' which tells an agent the call may be partitioned and slower, and explains why it catches decay that period comparisons miss.

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?

Three short sentences cover the problem statement, the reason a dedicated tool is needed, and the parallel-query behavior with no filler. The rationale is front-loaded before the operational note.

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 9-parameter tool with an output schema and safety annotations, the description explains the key conceptual model and runtime behavior without needing to repeat parameter documentation. It could be more complete by explicitly naming the type of result returned, but the output schema fills that gap.

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 89%, so parameters like months, date_to, row_limit, and site_url already carry meaning. The description adds no direct parameter syntax or examples beyond the schema, which is acceptable at this coverage level.

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 phrase 'Pages sliding down month after month' communicates the tool's focus on gradual multi-month decay, and the note that period comparison misses it differentiates this from a generic month-over-month diff. It lacks an explicit verb like 'detect' or 'return,' so it stops short of a crisp 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 when to use the tool: for slow declines that a period comparison would hide. It does not name sibling tools or state an explicit when-not-to-use, so the routing guidance is 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 read-only, idempotent, and non-destructive behavior, so the description is free to add conceptual depth. It explains that the snippet, not ranking, is the problem, and defines expected_ctr as the position-based benchmark, which is valuable beyond the structured 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 three short sentences with no filler. The opening sentence states the core concept, the second adds strategic value, and the third defines the key benchmark term.

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 rich parameter schemas, safety annotations, and an output schema, the description provides enough conceptual context for an agent to understand what the tool offers. The only clear gap is explicit routing among sibling tools, which is already penalized under usage guidelines.

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 92%, so the schema itself documents nearly every parameter. The description only adds context for the expected_ctr field, which is an output concept rather than a parameter, so it does not materially enhance parameter understanding.

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 identifies Search Console rows that rank well but earn fewer clicks than their position implies, which defines the CTR-gap analysis concept. It lacks an explicit verb like 'list' or 'find', but the resource and analytical angle are 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 phrase 'cheapest fixes available' implies a prioritization use case, but the description never explicitly states when to use this tool instead of siblings such as gsc_quick_wins or gsc_query. This is implied context rather than actionable routing 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 mark it read-only and idempotent; the description adds what the report contains (auth mode, token expiry, property count, cache state, defaults) and promises secrets are masked. This gives the agent confidence about side effects and output contents. No contradiction with 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?

Two short sentences with the core purpose first, followed by valuable specifics. Every word earns its place; the 'Secrets are masked' note is important but not over-explained.

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 zero-parameter diagnostic tool with an output schema, the description explains when to call it and what information it will surface. It covers purpose, usage timing, and behavior without omitting anything the agent needs to invoke it 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?

The tool takes zero parameters, so the schema carries no burden and the description doesn't need to explain parameter meanings. Per the baseline for zero-parameter tools, this is a 4.

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?

States a specific verb ('Report') and resource (server configuration and Search Console connectivity). Clearly distinguishes from sibling tools that query search data. The 'Call this first' line reinforces its role as a diagnostic entry point.

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?

Explicitly instructs 'Call this first when something fails', which is a clear trigger condition. Also explains that it reveals defaults every other tool applies, so it is meant as a pre-flight check for subsequent calls. No exclusions are needed because it's unambiguously the diagnostic tool.

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?

Beyond the readOnly/idempotent annotations, the description discloses concurrency, one row per input URL in input order, per-URL error columns, partial batch results, quota limits, and the exact result columns. This is rich behavioral context an agent cannot infer 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 well-structured and front-loaded: the core purpose appears in the first sentence, followed by behavioral details, alternative routing, quota, and output columns. Every sentence adds usable information without padding.

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 description covers purpose, behavior, error handling, quotas, output columns, and the relevant sibling tool. Combined with the thorough input schema and output schema, an agent has everything needed to select and invoke this 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?

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description does not add parameter-level detail, but it does provide output-column context and quota constraints that indirectly help the agent understand what the parameters produce.

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 opens with a specific verb and resource: 'Check whether a batch of URLs is indexed, and why not when they are not.' It clearly distinguishes this batch tool from the single-page alternative by naming gsc_inspect_url and contrasting batch rows versus full payload.

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 explicitly tells an agent when to use this tool versus gsc_inspect_url: for batch indexing checks versus full single-page payloads. This gives clear selection guidance without ambiguity.

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, so the safety profile is covered. The description adds valuable rate-limit context (600/min and 2,000/day per property) and signals that a single URL is being inspected, extending beyond what annotations say without contradicting 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 three short, purposeful sentences: what it does, when to use it, and its quota. It is front-loaded with the core action and contains no filler. Every sentence 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?

For a single-URL inspection tool with a complete input schema, rich annotations, and an output schema, the description covers the essential behavioral, quota, and sibling-selection context. Nothing needed to select or call the tool correctly is missing.

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 100%, so the schema already explains all parameters, including the site_url format and the no_cache option. The description does not add parameter-level detail beyond what is in the schema, so the baseline score of 3 is appropriate.

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 opens with 'Full URL Inspection for one page' and enumerates the inspected dimensions: index, mobile, rich results, and AMP. It also names the sibling tool gsc_indexing_issues for the multi-URL sweep, making the tool's scope unambiguous. This clearly differentiates it from its siblings.

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 states 'Use this when one page needs a diagnosis' and contrasts this with 'an indexed-or-not sweep across many URLs' pointing to gsc_indexing_issues. This gives the agent an explicit decision rule between the tool and its closest alternative.

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 indicate a safe read-only operation. The description adds useful behavioral context beyond that: comparison with the previous period is the default, and position_delta semantics ('negative when the average position improves') are explained. This helps the agent interpret results correctly.

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?

Three tight sentences, each earning its place: the first states function, the second gives the primary use case, and the third clarifies an important metric interpretation. Information is front-loaded 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 read-only overview tool with a full input schema and an output schema present, the description provides all the behavioral guidance an agent needs: what it returns, the default comparison behavior, and the key metric nuance. Nothing important is missing.

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 100%, so the parameters are already fully documented. The description adds no new parameter-level meaning; it mainly reinforces compare_previous default behavior implicitly. This is the expected baseline when the schema carries the load.

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: 'Site totals for a period' with comparison to the preceding period and 'percentage change on every metric.' The 'Start here' framing and 'is the site up or down' metaphor make the purpose immediately understandable, though no sibling tool is explicitly named for differentiation.

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 explicitly tells the agent when to use this tool: 'Start here: it answers "is the site up or down" in one call.' This provides clear context for choosing this tool first, but it does not explicitly state when to prefer alternatives or when not to use it.

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 the description only needs to add context beyond that. It adds meaningful behavioral details: results are ranked worst first, each row compares current vs. previous period, and health thresholds are explicitly defined (critical below -30% clicks, warning below -15%). This is useful behavior that the annotations do not convey.

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 compact, front-loaded with the tool's core purpose, and every sentence adds useful information. It avoids restating schema fields or repeating annotation hints, containing only the essential decision-making context an agent needs.

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 portfolio overview tool with an output schema and strong annotations, the description covers the key context: scope (all accessible properties), ranking, period comparison, health thresholds, and when to use it. It does not explain every parameter in prose, but the schema already covers most of those. Minor gaps like the meaning of 'accessible' or the effect of no_cache are understandable given the availability of schema and 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 80%, and the parameter descriptions already handle days, limit, date_to, and response_format. The description does not add parameter-specific semantics beyond what the schema provides. The health-flag thresholds describe output behavior, not parameter meaning, so the baseline of 3 is appropriate.

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 that the tool returns every accessible property at a glance, ranked worst first, with one row per property and a health flag. This distinguishes it from sibling tools like gsc_site_details or gsc_query, which operate on individual properties or specific metrics, by establishing its role as a portfolio-level overview.

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 gives clear usage context: 'Use it to decide which property to look at before running anything else.' This tells the agent that this should be the first triage step. It does not explicitly name alternatives or exclusions, but the 'before running anything else' guidance makes the intended placement in a workflow clear.

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 mark the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds meaningful behavioral context beyond the schema and annotations: the default 28-day end-to-today window, inclusion of today's partial data via data_state=all, the TSV or JSON output shape, and the meta fields needed for pagination such as start_row and whether more rows exist.

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 compact and front-loaded: purpose first, then key defaults, then an example, then the return envelope. Every sentence earns its place, and the example is a high-signal compact illustration of how the parameters combine.

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 large 15-parameter schema with 100% coverage, plus an output schema and strong annotations, the description supplies exactly the missing context: default period semantics, UI parity, API-style pagination, and a representative call. An agent has enough to both select and 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?

Schema description coverage is 100%, so the baseline is 3, and the schema already documents every parameter clearly. The description adds value with a concrete example tying site_url, dimensions, period, and row_limit together, and it clarifies default date behavior and the pagination contract. That moves it above baseline without duplicating 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 opens with a specific verb and resource: 'Query the Search Analytics report: clicks, impressions, CTR, position.' It then labels the tool as 'the general-purpose tool,' which distinguishes it from specialized sibling tools like gsc_quick_wins or gsc_ctr_gaps. This gives an agent a clear and immediate sense of scope.

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 clear context: it covers defaults, date behavior, and the UI-matching data_state, and it demonstrates usage with an explicit example. It identifies the tool as the general-purpose option, implicitly routing agents away from specialized siblings, though it does not name those alternatives or state explicit when-not-to-use conditions.

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, destructiveHint=false, covering safety. The description adds valuable behavioral details: ranking by potential clicks rather than impressions, and the existence of adaptive thresholds reported in the meta. This goes beyond what the annotations provide.

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 concise sentences. The first sentence clearly states the core function, and the second adds the critical ranking nuance. Every word earns its place; no fluff or 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?

Given the output schema exists, return values need not be explained. The description covers the key behavioral aspects, but it does not mention how conditions like threshold overrides interact with defaults, or any caveats about caching. Still, for a read-only analysis tool, it is sufficiently complete.

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 coverage is 92%, so most parameters are already documented. The description adds meaning by explaining the role of target_position in the ranking logic, which is not obvious from the schema alone. This supplements the parameter semantics usefully without needing to repeat schema details.

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 states a specific purpose: finding queries close enough to the top that a push would pay off. It clearly differentiates from other GSC tools by explaining the ranking logic (based on potential clicks at target_position, not impressions), which distinguishes it from similar tools like gsc_ctr_gaps or gsc_query.

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 the use case (identifying quick-win queries worth pushing) but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. The context is clear enough, but explicit routing to a sibling tool like gsc_query for general query analysis would improve it.

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 fully covered. The description adds that the tool exposes permission level and property type, but it does not disclose additional behavioral traits such as caching behavior or response details. There is no contradiction with 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 short declarative sentence with no filler. It front-loads the essential output information and earns its place entirely.

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, has an output schema, full parameter descriptions, and strong safety annotations, so the structured fields carry most of the context. The main description is minimal but adequate for invoking the tool; some additional context about interpreting 'permission level' would have been useful, but it is not critical given the 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 100%, and every parameter already has a meaningful description, including the site_url format, response_format options, and no_cache behavior. The tool description itself adds no parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.

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 identifies the resource scope ('for one property') and states the output focus: 'Permission level and property type.' It lacks an explicit retrieval verb such as 'Get' or 'Return', but it is still distinguishable from the sibling gsc_sites tool, which lists properties.

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 main description provides no when-to-use guidance and does not mention alternatives. The only routing hint, 'Call gsc_sites if unsure,' appears inside the site_url parameter description and concerns resolving a parameter value, not deciding whether this tool is the right choice.

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 mark the operation as readOnly, idempotent, and non-destructive. The description adds meaningful context beyond this by explaining the server never requests read-write scope, which is why submitting or deleting is impossible. It also discloses that returned data reflects what Google knows, with error and warning counts, adding 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 concise and front-loaded: the first sentence states the main purpose, the second adds the key read-only constraint, and the third summarizes the row shape. Every sentence earns its place with no fluff or repetition.

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?

Combined with the detailed input schema, annotations, and output schema, the description is complete enough for an agent to call this tool correctly. It explains scope, read-only policy, and the row contents, while the schema covers parameter formats. Nothing essential for selecting or invoking this tool is missing.

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 input schema description coverage is 100%, so the schema already documents site_url, no_cache, and response_format clearly. The main tool description adds little to parameter meaning. The baseline of 3 applies because the schema does the heavy lifting and the description does not need to compensate.

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 names a specific verb and resource: 'List the sitemaps Google knows about for a property, with errors and warnings.' It clearly identifies a listing operation on sitemaps with diagnostic data, which distinguishes it from sibling tools like gsc_query or gsc_sites. However, it does not explicitly compare itself to siblings or state what it is not, so it misses full differentiation.

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 gives clear context: this is a read-only listing tool and cannot submit or delete sitemaps because the server never requests read-write scope. This is a useful exclusion. It does not explicitly name an alternative tool to use for mutation or for site discovery, though the site_url schema description suggests gsc_sites when unsure.

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=false, so the safety profile is covered. The description adds valuable behavioral context beyond those hints: it returns exact site_url strings other tools expect and distinguishes domain properties from URL-prefix properties.

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?

Two tight sentences with no filler. The core purpose is stated first, and the practical usage instruction is directly after, making it easy for an agent to scan and act on.

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 output schema exists, annotations cover safety and idempotency, and parameters are fully documented, the description adds exactly the missing context: when to call this tool and what value it provides. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, so the parameters no_cache and response_format are already fully documented in the schema. The description does not need to add parameter details, and it does not, so the baseline score of 3 is appropriate.

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 and resource: 'List every property the authenticated account can read.' It clearly defines the tool's scope and distinguishes it from siblings like gsc_site_details or gsc_query by positioning it as the property-listing/discovery tool.

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 gives an explicit trigger condition: 'Call this first when a property string fails.' It also explains what the tool returns and how that helps with other tools, which gives an agent clear context for when to use it. It does not explicitly name alternative tools, but the unique listing purpose makes the usage boundary clear.

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 state readOnlyHint, idempotentHint, and destructiveHint, so the baseline is lower. The description adds meaningful behavior: it explains that each row includes a diagnosis and raw numbers for both periods, making the results auditable. This is useful context beyond the annotations, with no contradiction.

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 compact and front-loaded, stating the core purpose in the first sentence. The second paragraph adds genuinely useful diagnostic context without filler. Every sentence 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?

Given the tool has 10 parameters, an output schema, and detailed annotations, the description provides useful interpretive context but leaves gaps. It does not define what 'baseline' means, how thresholds are calculated, or how this tool relates to the many sibling diagnostics. Adequate, but not fully complete 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?

Schema description coverage is 90%, so the parameters are already well documented. The description does not add parameter-level detail, but it does contextualize the output by mentioning 'baseline' and 'both periods.' This is adequate given the schema already carries most of the burden.

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 identifies the output as pages that lost clicks against a baseline, each with a likely cause. It also adds diagnostic categories, making the purpose tangible. However, it lacks an explicit verb like 'returns' or 'identifies' and does not distinguish itself from sibling tools by name.

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 tool versus closely related siblings such as gsc_content_decay or gsc_ctr_gaps. The statement that the four diagnoses need different fixes is interpretive guidance for acting on results, not guidance for tool selection.

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