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

Annotations already cover the safety profile (non-destructive, idempotent, open-world write). The description adds real value beyond them: the required GSC_ALLOW_WRITE=1 environment flag and the caveat that verification occurs separately in Search Console, both of which an agent needs to invoke it 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?

Two compact sentences with the core action front-loaded. The parenthetical prerequisite is slightly disruptive but still efficient; no sentence is wasted.

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?

An output schema exists so return values need no explanation, and the prerequisite plus verification caveat are covered. However, with a mutation tool and an undocumented required parameter, the description leaves the agent guessing about site_url format and no format examples are given.

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 single parameter site_url has 0% schema description coverage, so the description carries the burden but does nothing to clarify it – no format guidance (e.g., domain property vs URL-prefix syntax), which is a common source of error for GSC properties. It fails to compensate for the coverage 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?

States a specific verb+resource ('Add a property to this account'), which clearly distinguishes it from list_properties/get_property/remove_property siblings. It doesn't explicitly name those siblings, so it falls just short of a 5.

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 purpose implies when to use it (creating a new property), and it notes that verification must still happen in Search Console, but it never states when to prefer this over alternatives or what preconditions guarantee success beyond the env flag. Usage is implied rather than spelled out.

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/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds real behavioral detail the annotations cannot: terms match spelling variants as whole words, and level=loose lets a 4+ character term match when glued to neighbours (toyotacamry). That rule is genuinely useful and non-obvious.

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 sentences, no filler, and the core concept is front-loaded. The opening sentence is a bare noun fragment rather than a full statement, which costs a point but is still 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?

An output schema exists so return values need no prose, but for a 9-parameter tool with 0% schema coverage the description covers only two parameters. Missing date-window, row-cap, source, and search_type semantics leave the agent guessing on the majority of inputs.

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 0%, so the description must carry the load. It does explain brand_terms (comma-separated, multiple scripts/spellings) and the level enum behavior, but leaves days, source, max_rows, search_type, site_url, and start/end_date entirely unexplained. Partial compensation only.

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 fragment "Brand vs non-brand traffic" plus the brand_terms guidance makes clear the tool segments traffic into brand and non-brand buckets. The verb is implied rather than stated (splitting/classifying), and no sibling is named for differentiation, keeping it below a 5.

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 explicit when-to-use, when-not-to-use, or alternative routing. With 35+ siblings such as query_variants, top_terms, and find_cannibalization, the agent gets no signal about when brand_split is the right pick over those.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing the RE2 ASCII-only \b rationale, the exact script-specific classes generated (Arabic ی/ي, ک/ك, ه/ة, Cyrillic е/ё), digit form handling, case-insensitivity, what loose=True does, and explicit limitations (accent and kana variants not covered). This is unusually rich behavioral context for a pure-computation 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?

Front-loaded with purpose and usage, then implementation detail; every sentence adds real information about matching behavior. Slightly dense with script-specific minutiae, but the complexity of the tool justifies it.

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?

An output schema exists, so return format need not be explained. Given the tool's complexity, the description covers purpose, usage, matching behavior, edge cases, and limitations thoroughly; 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 description coverage is 0%, so the description must carry parameter meaning. It explains loose=True ('lets words run together') and implies boundary handling via the whole_word concept, but never explicitly defines the whole_word parameter or the required term's format beyond 'a term'.

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 and resource: builds a Search Console regex for a term, with Unicode/spelling-variant scope. It is immediately distinguishable from sibling tools like query_variants or top_terms, which produce data rather than regex patterns.

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 states how to use the output: 'Use the result as query_regex in other tools or paste it into the Search Console UI (regex filter).' This gives clear context, though it does not name the specific sibling tools that accept query_regex or state 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 readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds two useful behavioral facts — results are ordered by biggest movers and queries are matched across spellings — but says nothing about rate limits, result volume, or what happens when compare periods overlap.

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?

Front-loads the core purpose and ordering behavior, then moves into parameter enumeration with no filler. The dense inline lists are compact, though slightly cramped to parse.

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?

An output schema exists, so return values need not be explained. However, for a 13-parameter analytical tool with zero schema coverage, the description leaves more than half the parameters unexplained and gives no guidance on level, search_type, or filter interactions.

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 0% across 13 parameters, so the description carries the full burden and only partly does so. It fully enumerates compare_to's four modes and dimension's five values (neither of which appears as an enum in the schema) and notes custom's prerequisite params — genuinely valuable — but days, level, limit, site_url, search_type, and the three filter params remain undocumented.

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 and resource ('Compare a period with an earlier one') plus an output-shape detail ('biggest movers first'), so the agent knows what it returns. It does not explicitly distinguish itself from the sibling history_compare, which likely covers similar ground, so it falls short of a 5.

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 real guidance on one decision point: compare_to values and the fact that 'custom' requires previous_start/previous_end. But it never says when to choose this tool over performance_overview, query_search_analytics, or history_compare, so usage is implied rather than directed.

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 this as a read-only, idempotent, open-world, non-destructive operation. The description adds useful behavioral context by defining the result categories (decayed, rising, lost, new) and the comparison modes. It does not discuss auth requirements, rate limits, or pagination, but with safety annotations present this is a reasonable level of detail.

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-loads the core purpose. The subsequent lines efficiently define compare_to values and output categories. It wastes little space, though it could be organized slightly more clearly for an agent scanning parameter semantics.

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 12 parameters, 0% schema description coverage, and no parameter-level documentation in the description. Although an output schema exists and annotations cover the safety profile, the description does not sufficiently explain how to invoke the tool or how it differs from sibling analytics tools. It is incomplete for a parameter-heavy, open-world reporting operation.

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 0% and there are 12 parameters, so the description carries a heavy compensation burden. It explains compare_to options (which the schema does not enumerate) and hints at dimension via 'Pages (or queries)', but leaves days, limit, source, max_rows, start_date, end_date, search_type, and min_previous_clicks entirely unexplained. The coverage is too sparse for a tool of this complexity.

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 report: pages or queries whose clicks moved by at least a threshold versus an earlier period. The added category definitions (decayed, rising, lost, new) clarify what the output represents. It does not explicitly distinguish itself from sibling tools such as compare_periods, but the core purpose is clear.

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 the available compare_to modes and their meanings, which helps an agent choose how to compare periods. However, it does not say when to use this tool versus alternatives like compare_periods, striking_distance, or low_ctr_opportunities. Usage is implied rather than explicitly guided.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds some domain semantics about final versus changing recent days, but it does not disclose auth requirements, rate limits, or other behavioral constraints 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 front-loaded sentence with no wasted words. It is appropriately sized, though its brevity contributes to the gaps in parameter and usage guidance.

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?

An output schema exists, so return values need not be described, and annotations cover safety. However, with 0% schema coverage, the description should compensate for parameter meaning and usage guidance, which it does not. An agent lacks enough context to invoke the tool confidently.

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 0% for two parameters: required site_url and optional search_type with default 'web'. The description does not explain what either parameter means or what values are expected. The phrase 'daily and hourly data' does not clearly map to search_type or compensate for the missing schema documentation.

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 clear query purpose: identifying which recent days are final versus still changing, for daily and hourly data. It is understandable without opening the schema, but it does not distinguish this tool from related siblings such as history_status or performance_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?

There is no explicit guidance on when to use this tool, when not to use it, or which sibling tool to choose instead. The description implies a freshness-check use case but leaves the agent to infer the appropriate 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds high-value context beyond them: the required write-enable flag and the crucial clarification that 'The file itself is untouched' — directly countering the intuition that a destructive delete removes the file.

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 zero filler, front-loading the action and immediately following with the two facts an agent most needs (the env flag and the file-safe behavior).

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?

An output schema exists so return values need no explanation, and the write prerequisite plus the 'file untouched' clarification cover the key behavioral risks for a destructive tool. Only the parameter meanings remain unaddressed.

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 0% for two required parameters (site_url, sitemap_url), and the description supplies no meaning for either — no format, no distinction between the property and the sitemap. It fails to compensate for the coverage gap, though the names are largely self-describing.

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 and resource ('Remove a sitemap from Search Console'), which cleanly distinguishes it from siblings like submit_sitemap, list_sitemaps, and get_sitemap. An agent can identify the operation without opening the schema.

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 the non-obvious precondition that GSC_ALLOW_WRITE=1 must be set, which is real usage guidance. It does not, however, contrast with alternatives (e.g., why delete vs. just stop submitting) or state when-not-to-use.

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 the read-only, idempotent, open-world safety profile, but the description adds genuinely non-obvious behavior: spelling variants of a query are merged before comparison, and results are ranked by wasted impressions. That is real behavioral context beyond the structured fields.

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?

Front-loaded with the core definition, then the deduplication rule, then the min_share definition — no filler. The mid-sentence line breaks and the guillemet example add minor noise but the sizing is appropriate.

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 12-parameter tool, this is only partially complete: the purpose and one key parameter are covered, and an output schema exists so return values need no explanation. However, most tunable parameters and any usage routing are absent, leaving an agent unable to reason about level, source, or date-window 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 0% across 12 parameters, so the description carries the burden of explaining them — yet it clarifies only min_share. days, level, source, search_type, limit, max_rows, query_filter, min_impressions, and the date fields are all left undocumented, and level/source/search_type have no enum hints anywhere.

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 analytical operation on a named SEO concept: pages competing on the same query, ranked by impressions lost to the non-best page. This is clearly distinguishable from neighbors like query_variants, striking_distance, or queries_for_page.

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 explains what the output means but never says when to reach for this tool versus sibling diagnostics (e.g., query_variants for spelling issues, striking_distance for ranking opportunities). No prerequisites or exclusions are given, leaving routing to inference.

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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the description's burden is lower. It does add useful content scope by naming the returned facts, but since an output schema exists that already documents the response shape, this disclosure is partly redundant and adds only moderate behavioral value.

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 fragments, zero filler, and the payload summary is front-loaded ahead of the call-order advice. Every clause 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 rich annotations, a full output schema, and no parameters, this simple discovery tool needs little more than what is given. The description tells the agent what facts it returns and when to reach for it, which is sufficient 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?

The tool takes zero parameters, so there are no parameter semantics to document and the baseline of 4 applies. The description does not misleadingly imply any inputs.

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 enumerates the specific payload of the tool: auth status, scope, write access, history coverage, and the tool list. That is concrete enough for an agent to know this is a capabilities/diagnostics probe rather than a data-query tool. It does not name a sibling it overlaps with, but its role is distinctive among the query-oriented 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?

"Call this first when unsure" gives an explicit trigger condition and a preferred ordering relative to the rest of the toolset. It lacks an explicit when-not clause or named alternatives, but the guidance is actionable as written.

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 covered. The description adds one genuinely useful behavioral trait - input normalization of loose values like 'example.com' - but no auth, rate-limit, or error context.

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, front-loaded with the returned data and followed by the input-handling note. Nothing is wasted.

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?

An output schema exists, so return values need not be described, and annotations cover the read-only/idempotent profile. For a single-parameter lookup the description is nearly sufficient, with only the usage-vs-siblings decision left unstated.

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 0%, so the description must carry meaning, and it does partially by clarifying that site_url tolerates loose input. It does not state the expected canonical format or how normalization affects matching, leaving a gap against the compensation 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?

States a specific verb+resource: retrieve details (exact URL and permission level) of one property. The word 'one' implicitly distinguishes it from list_properties, but no sibling is named explicitly, keeping it short of a 5.

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?

Gives input-format guidance ('accepts loose input like example.com') but no when-to-use, when-not, or alternative routing. An agent cannot tell from this text why it would choose get_property over list_properties or inspect_url without reading other definitions.

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, openWorldHint and destructiveHint=false, so safety is fully covered. The description adds the shape of returned data, but with an output schema present that is largely duplicate information rather than new behavioral context.

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?

A single front-loaded sentence fragment with zero filler and the resource named first. It is efficient, though the telegraphic style omits an explicit verb.

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?

An output schema exists so return values need not be spelled out, and annotations carry the safety profile. However, with 0% parameter coverage and no usage guidance, an agent still lacks enough to invoke this confidently against its many siblings.

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 0% and both required parameters (site_url, sitemap_url) are bare strings with no descriptions. The description does not say what either parameter accepts or the relationship between them, so it fails to compensate for the schema 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?

States the resource ('one sitemap') and enumerates the specific payload it returns (submission/download dates, errors, warnings, per-type URL counts). 'One sitemap' implicitly distinguishes it from the sibling list_sitemaps, though no sibling is named explicitly.

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 statement of when to use this tool versus list_sitemaps, submit_sitemap, or delete_sitemap, and no prerequisites (e.g., needing a verified property). Usage must be inferred from the name alone.

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 covered. The description adds useful context that this reads stored history rather than the live API, but says nothing about retrieval cost, freshness of stored data, or how the two periods are aligned.

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 core purpose and the example are front-loaded in one tight sentence, with no wasted prose. The dangling 'dimension: query, page, country or device' fragment is the only structural weakness, reading like a stray note rather than integrated guidance.

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?

Although an output schema exists (so return values need not be explained), the tool has 8 parameters with no schema descriptions and only one of them partially addressed in prose. For a comparison tool whose correctness depends on correctly pairing start/end with previous_start/previous_end, the definition leaves too much implicit.

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 0% across 8 parameters, so the description carries the full burden and largely fails. It only clarifies that 'dimension' accepts query/page/country/device (values not enumerated in the schema), leaving site_url, start_date, end_date, previous_start, previous_end, limit, and search_type completely uninterpreted.

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 gives a specific verb ('Compare') and resource ('two stored periods') with a concrete example of what a comparison looks like. The phrase 'beyond the API's 16 months' signals this operates on locally stored history rather than live data. It falls short of a 5 because it does not distinguish itself from the sibling 'compare_periods', which an agent could easily confuse it with.

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?

Usage is only implied: the 'beyond the API's 16 months' clause hints that this is the tool for periods the live API cannot cover. There is no explicit when-to-use/when-not statement, and no mention of the competing 'compare_periods' sibling, so the agent must infer the routing decision.

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 safe read-only/idempotent profile, so the description rightly spends its words elsewhere: it discloses that queries are merged across spellings and that matching is done on a multilingual match key (e.g. Arabic diacritics, spaceless CJK). That is real behavioral context beyond the annotations, though it omits any note on default limit/pagination behavior.

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 paragraphs, front-loaded with the core purpose and then the parameter hints. Every sentence earns its place; only the trailing newline/formatting is slightly rough.

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?

An output schema exists so return values need not be described. However, for a 10-parameter tool with 0% schema coverage and no usage guidance, the description is far from sufficient: an agent cannot confidently fill eight of the ten arguments from the text alone.

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 0% across 10 parameters, so the description carries the full burden. It explains the values accepted by 'dimensions' and the matching semantics of 'query_contains', which is genuinely useful, but leaves site_url, start_date/end_date format, search_type, device, country, page_contains, and limit entirely undocumented.

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 and resource ('query the local history') plus a scope qualifier ('grouped by dimensions'), which tells the agent this is an aggregation/grouping query. It does not, however, differentiate itself from close siblings such as history_trend, history_compare, or history_sql, which the agent must otherwise infer.

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 when-to-use or when-not-to-use guidance and no mention of the sibling alternatives in the same history_* family. The agent is left to infer that this is the general-purpose grouped-history tool rather than history_trend/history_compare/history_sql.

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/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that: it exposes the data model (tables, columns) and the semantic meaning of qkey as the multilingual match key. It stops short of disclosing row caps, cost, or query restrictions.

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?

Front-loaded with the action and read-only constraint, followed by a compact table/column inventory. Efficient and well-ordered, with only the brief qkey clarification as an addendum.

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 raw-SQL tool with an output schema (so return values need no explanation) and full annotation coverage, the description supplies the critical data model. What it omits is usage context relative to the numerous structured history/analytics siblings, leaving the agent to guess when raw SQL is the right choice.

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 0%, so the description must carry the burden. It does document the queryable schema, which is essential for writing the `sql` parameter, but it never explains the `limit` parameter or any syntax expectations for the SQL string.

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 and resource ("Run a read-only SELECT on the history database") and then names the queryable tables and their columns, so the agent knows exactly what it can query. It does not explicitly distinguish itself from siblings like history_query or query_search_analytics, so it falls short of a 5.

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 reach for raw SQL versus the many structured siblings (history_query, history_trend, query_search_analytics). The only constraint given is "read-only SELECT," which is a restriction, not a routing rule.

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, so safety behavior is covered. The description adds that it reports coverage metadata (first/last day, rows, final days), which is useful context about the return content beyond mere 'status', but no auth requirements or limitations are mentioned.

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?

One concise sentence, front-loaded with the subject. No wasted words, though the fragment structure is slightly terse.

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 a read-only, idempotent tool with an output schema, the description need not explain return values. However, it should clarify the relationship with sibling history_* tools and the optional site_url semantics. It is minimally adequate but leaves 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 0% for the single site_url parameter. The description does not explain what site_url controls or whether omitting it returns all properties. Baseline 3 when a single parameter exists and schema adds nothing.

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 what the tool reports (local history contents: per property, search type, first/last day, rows, final days) but does not use a clear verb like 'retrieve' or 'list' and offers no differentiation from sibling tools like history_query or history_trend. An agent must infer that this is a status/metadata report rather than a data-fetching 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?

No guidance on when to use this tool versus history_query, history_trend, history_compare, or history_sql. The agent is left to guess based on the name and vague 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that data comes from local history and supports any length of time, which is useful behavioral context, but it does not cover pagination, rate limits, auth needs, or result behavior.

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?

It is a single, front-loaded sentence that states the core metrics, granularity choices, data source, and range flexibility without any filler. Every phrase 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 7-parameter tool with 0% schema description coverage and several sibling history tools, the description is too thin. While it correctly avoids explaining return values because an output schema exists, it omits parameter formats, filter behavior, and when to prefer this over adjacent tools.

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 0% across 7 parameters, so the description must compensate. It only clarifies the granularity options ('per day, ISO week or month'), leaving site_url, start_date, end_date formats, search_type, page_contains, and query_contains undocumented in both schema and description.

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 names the metrics returned (clicks/impressions/CTR/position), the time grouping options, and the local-history source. It is understandable as a trend/performance-over-time tool, though it does not explicitly differentiate itself from siblings such as history_query or query_search_analytics.

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 no guidance on when to use this tool versus alternatives like history_query, history_compare, performance_overview, or query_search_analytics. It also omits prerequisites or conditions for choosing local history over other data sources.

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, idempotent, non-destructive and openWorld, so safety is covered. The description adds real behavioral context beyond them: the 10-day cap, that the most recent points are preliminary/incomplete, and that Search Console's native daily numbers are Pacific-Time days while timezone re-cuts them into local days/hours.

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, front-loaded paragraphs: the core identity statement, the hours=24 vs days branch, and the timezone nuance. Sentence economy is good, though the timezone paragraph is dense and could be marginally tighter.

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?

An output schema exists so return values need not be described, and the temporal/timezone semantics are well covered. However, with 8 parameters at 0% schema description coverage and no mention of the filter or search-type parameters, the description leaves notable gaps for an otherwise complex tool.

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 0% across 8 parameters, so the description must carry parameter meaning. It explains by, days, hours, and timezone well (including the local-time re-cutting semantics), but says nothing about site_url, page_filter, query_filter, or search_type, leaving half the parameters undocumented.

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 verb+resource (hourly Search Console performance data for the last 10 days) and explicitly differentiates its niche from siblings: it reproduces the Performance report's 24-hour view and is 'the only way to get true LOCAL days.' An agent can distinguish it from performance_overview and query_search_analytics without opening the schema.

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 clearly specifies the branching condition: hours=24 reproduces the 24-hour report view including preliminary points, otherwise the last `days` (max 10) are returned. The timezone behavior (re-cut into local days via by=day or per local hour via by=hour) tells the agent when to use which mode. No explicit exclusion or sibling routing by name, but usage context is unambiguous.

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 safety is covered. The description adds useful behavioral context beyond annotations by stating the result is filtered to problems only, includes reasons, and is capped at 50 URLs.

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 extremely concise and front-loaded with the key constraint 'Problems only'. Every clause adds useful information, and there is no 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?

An output schema exists, so return format need not be explained. The description covers purpose, output filtering, and the URL limit, but leaves the 0%-documented parameters largely unexplained despite having four parameters and two required ones.

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 0% for four parameters. The description only vaguely references 'given URLs' and the 50-URL cap; it does not explain site_url, language, or concurrency, so it fails to compensate for the missing schema documentation.

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 diagnostic outcome: identifying which given URLs are not indexed or have structured-data failures, plus the reason. It does not explicitly name or compare against sibling tools like inspect_urls, so sibling differentiation is left implicit.

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 'Problems only' implies this tool should be used to surface problematic URLs rather than complete inspection status, and 'Up to 50 URLs' states a hard limit. However, it gives no explicit when-to-use versus inspect_urls or other siblings, nor prerequisites.

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 safety is covered. The description adds genuine external context the annotations lack: the daily quota ceiling (~2,000/day) and the 'today' reset window, which is exactly the behavioral fact an agent needs.

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?

One sentence, front-loaded with the core purpose and ending with the quota context. No filler; every clause carries useful information.

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-parameter read tool with an output schema (which handles return values) and annotations covering safety, the description is nearly complete. A brief note on parameter format would close the remaining 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 coverage is 0% and the single site_url parameter is undocumented, so the description must compensate. 'For a property' loosely maps the parameter to a property identifier, but it doesn't clarify the expected URL/identifier format, so this only partially fills the 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?

States a specific resource (URL inspection quota) and scope (today, per property), which is clearly distinct from the sibling inspect_url/inspect_urls tools that actually perform inspections. The verb is implicit in 'How many...has used' but the intent is 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?

Usage is only implied: the '(Google allows ~2,000/day)' note hints you should check this before bulk inspections, but the description never states when to call it, that it's a pre-flight check, or which sibling it complements.

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, idempotent, non-destructive, openWorld, so the safety profile is fully covered. The description adds what content the inspection returns, which is useful, but says nothing about quotas (note the sibling inspection_quota), permissions, or latency that would materially affect invocation.

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?

A single front-loaded sentence with no filler; the facet list is compact and informative. It is a noun phrase rather than a sentence, but nothing is wasted.

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?

An output schema exists, so return-value explanation is not required, and annotations carry the safety profile. However, for a two-required-param tool with zero schema descriptions, the missing explanation of site_url vs page_url leaves the definition incomplete 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 coverage is 0% and the description explains none of the three parameters. The critical distinction between site_url (the property) and page_url (the page being inspected) is left entirely unexplained, which is exactly the ambiguity an agent needs resolved for URL Inspection 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?

States a specific verb+resource (inspect a URL) and enumerates the inspection facets covered (index verdict, crawl, canonical, robots, sitemaps, rich results, mobile). The phrase 'for one page' implicitly separates it from the sibling inspect_urls, but does not name that sibling explicitly.

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?

Usage is only implied: 'for one page' hints that batch inspection belongs to inspect_urls, but the description never states when to prefer this over the sibling or any prerequisites (e.g., property ownership/verification). Adequate but leaves routing to inference.

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 readOnly, idempotent, and non-destructive safety, so the bar is lower. The description adds genuinely useful operational context: quota is checked first, and URLs not reached within the time budget are marked and can be re-sent. It does not, however, describe failure modes for invalid URLs or what a partial-batch outcome looks like beyond the 'marked' note.

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?

Front-loads the core action and batch limit, then adds a compact column-semantics note. The two-verdict explanation ('a page can PASS one and FAIL the other') is a slightly unusual digression but earns its place by preventing misinterpretation.

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?

An output schema exists, so return-value explanation isn't required, which is a plus. But with 0% parameter description coverage across 4 params and no explicit quorouting vs the inspect_url sibling, the description leaves key calling details for the agent to infer.

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 0%, so the description must compensate for four undocumented parameters. It only clarifies the 'urls' format (comma-/newline-separated), leaving site_url, language, and concurrency entirely unexplained. This is a substantial gap given zero schema-level parameter documentation.

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 and resource ('Inspect up to 50 URLs in parallel') and clarifies the batch scope, distinguishing it from the singular sibling inspect_url. However, it doesn't explicitly say how it differs from inspect_url, so the sibling separation is inferred from the name and 'in parallel' phrasing rather than stated.

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 bulk usage ('up to 50 URLs in parallel', comma/newline separated) and mentions quota checking first, but does not explicitly state when to use this over inspect_url, when to avoid it, or prerequisites. Usage context is implied rather than 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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real depth beyond that: it guarantees precision ('a hit is reported only when the remapped text is a query that really appears in the data') and warns that include_unmatched=True introduces false positives. That precision/precision-loss contract is exactly the kind of behavioral context annotations cannot 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?

Front-loads the core concept in sentence one, then layers the precision rule and the parameter caveat. The illustrative example (rather than abstract prose) makes the definition compact and usable. Slightly dense, but every sentence adds information.

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 output schema exists, so return-value explanation is unnecessary, and the tool's core idea plus the layouts/flag semantics are covered. Still incomplete for a 9-parameter tool: no sibling routing and six parameters are left entirely unaddressed, so an agent must guess at date-range, source, and row-limit 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 coverage is 0% for 9 parameters, so the description must carry the load. It meaningfully documents only two: layouts (value list and what fa/fa2 mean) and include_unmatched. Key params such as days, source, search_type, max_rows, start_date, and end_date are undocumented in both schema and description, leaving most of the surface unexplained.

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 and resource (queries typed on the wrong keyboard layout) and immediately grounds it with a concrete example ('ovdn lhadk' = «خرید ماشین»). This is clearly distinguishable from the sibling analysis tools (query_variants, language_breakdown, top_terms), so an agent can tell what class of finding this returns without opening the schema.

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 explains the include_unmatched tradeoff well ('more findings, some false positives'), which is genuine usage guidance for that flag. However, it never states when to reach for this tool over neighbors like query_variants or language_breakdown, and gives no prerequisites or scoping advice; usage is mostly implied by the concept.

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, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds only the metric definition and no behavioral context such as date-range defaults, row limits, or freshness/caveats beyond what 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?

A single, front-loaded sentence with no filler; it states the measure and the grouping dimension immediately. It is tight, though it could have spent one more clause on usage rather than examples.

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?

An output schema exists, so return values need not be explained. However, for a 7-parameter tool with zero parameter documentation, no date-window behavior, and no routing guidance among many similar analytics siblings, the description is materially incomplete.

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?

Seven parameters with 0% schema description coverage, and the description mentions none of them. Fields like days, max_rows, source, search_type, start_date and end_date are completely undocumented in both the schema and the description, leaving the agent to guess at 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 names a specific metric (share of clicks and impressions) and a specific dimension (script/language of the query), with concrete examples (Persian vs Arabic vs Latin). It is clear what the tool computes, but it never distinguishes itself from siblings like query_search_analytics, top_terms, or brand_split.

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 when-to-use or when-not-to-use guidance and no named alternative. An agent cannot tell from the text why it would pick this over other segmentation tools such as brand_split or query_variants.

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, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds that it includes permission level per property, but no pagination, rate limits, or result ordering details. Annotations do the heavy lifting here.

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 resource. Zero waste, 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?

Output schema exists, so return values need not be described. The description adds the meaningful detail that permission level is returned, which helps an agent decide to call it. With annotations covering safety and output schema covering structure, this is nearly complete, though it could mention the lack of pagination.

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?

Zero parameters, so baseline is 4. The description correctly notes the tool takes no filtering criteria, which is consistent with the empty 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?

Specific verb + resource ('List every Search Console property this account can see') with additional scope qualifier (permission level). Clearly distinguishable from get_property (singular) in sibling list.

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 broad enumeration use case, but provides no explicit guidance on when to use list_properties vs get_property or add_property. Usage is inferable from the verb 'list' but not spelled out.

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, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context about the returned data, specifically that results include errors/warnings and URL counts, which helps set expectations for the response.

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 concise sentences with no wasted words. The purpose and return content come first, followed by the key parameter usage, making it well front-loaded and easy to scan.

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 read-only listing tool with a rich annotation set and an output schema, the description is largely complete. It covers the resource, returned contents, and the optional sitemap_index behavior, though sibling differentiation could be stronger.

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 0%, so the description must compensate. It explains sitemap_index well by stating that passing it lists children, but site_url is only implied by 'for a property' and is not explicitly named or clarified.

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 and scope: sitemaps submitted for a property, including errors/warnings and URL counts. It effectively distinguishes this as a listing tool for a property's sitemaps, though it does not explicitly name or contrast with sibling tools like get_sitemap or submit_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?

It provides a conditional usage hint: 'Pass sitemap_index to list its children.' However, it does not state when to use this tool versus alternatives such as get_sitemap, submit_sitemap, or delete_sitemap, leaving broader usage guidance implied.

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, so the safety profile is covered. The description earns credit for disclosing the analytical methodology (site median per position when data suffices, otherwise a benchmark curve, and how ratio is applied), which is real behavior beyond the annotations. It says nothing about how the 'enough data' threshold is decided or about row limits/pagination, leaving those gaps.

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, front-loaded with the core definition before the methodology. Every sentence carries information and nothing is padded. Only minor deduction for the methodology clause being formatted loosely rather than 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?

An output schema exists, so return values need not be described, and annotations cover safety. But with 12 parameters at 0% schema coverage, the description is not complete enough for an agent to use the filtering knobs correctly. Adequate for the core concept, insufficient for 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 0% across 12 parameters, so the description carries the full burden, yet it only explains ratio ('0.5 flags rows under half the expected CTR'). It implicitly hints at max_position via 'page one' and at min_impressions via 'when there is enough data', but days, limit, source, search_type, start_date, end_date, max_rows and query_filter are entirely unexplained.

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+resource: query/page pairs on page one whose CTR underperforms their position, plus the diagnostic intent (title/snippet work). An agent can identify it as a CTR-anomaly detector. It does not explicitly distinguish itself from siblings like striking_distance or content_movers, which likely also surface underperformance, so it stops short of a 5.

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?

Usage is implied rather than stated: the closing phrase 'title/snippet work' signals the remediation context, and 'page one' scopes it to visible results. There is no explicit when-to-use-vs-alternatives guidance, no mention of excluding pages still in striking distance, and no prerequisite notes beyond the required site_url.

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 this a safe, idempotent, read-only, open-world operation, so the safety burden is covered. The description adds genuine behavioral context by noting it aggregates across spellings/variants and splits impressions between pages. It says nothing about date-range defaults (days=28), result limits, or auth requirements.

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?

A single sentence, front-loaded with the core purpose and the two dimensions (spellings, impression split). Every clause carries meaning with no 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?

With 8 parameters and zero schema description coverage, the definition is materially incomplete for invocation: default windows, the meaning of 'level', result limits, and date handling are all unaddressed. The output schema relieves it of explaining return values, but the input side remains a black box.

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 0% across 8 parameters, so the description carries the full explanatory burden. It only gestures at the query concept and impressions, leaving days, level, limit, start_date, end_date, and search_type entirely unexplained in both schema and prose.

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 gives a specific verb+resource: which pages rank for one query, split by spelling and impressions. This clearly positions it as the inverse of the sibling queries_for_page and distinct from query_variants. It stops short of naming an alternative explicitly, so it does not reach 5.

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 when-to-use or when-not-to-use guidance, and no alternatives are named. An agent must infer from the description alone that this is the page-side view of a query rather than the query-side view (queries_for_page).

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, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds useful behavior — the output inventory and the auto-granularity thresholds — but says nothing about rate limits, property/permission requirements, or whether missing start/end dates fall back to 'days'. 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?

Front-loaded with the payload summary first, then the granularity caveat, so the agent reads the important routing detail early. It is short and mostly earns its place, though the line-broken formatting is slightly awkward.

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?

An output schema exists, so return values need not be described, and the annotations cover safety. However, with 7 parameters at 0% schema coverage and a date-range/days interaction unexplained, the description leaves meaningful gaps for a tool whose main confusion point is date and granularity handling.

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 0% across 7 parameters, so the description must carry the load, yet it only explains granularity (its values and the auto behavior). site_url, top, days, start_date, end_date, and search_type are left entirely to schema defaults with no semantics or interaction rules (e.g., how start_date/end_date relate to days).

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 deliverable — a one-screen summary containing totals, trend, top queries/pages, devices, countries, and data freshness — which is a concrete resource description. It partially differentiates from siblings by naming hourly_performance for the hourly case, though it doesn't distinguish itself from query_search_analytics, compare_periods, or data_freshness.

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 gives a clear routing rule: use this for day/week/month granularity, and switch to hourly_performance for hourly data. The 'auto' explanation (day up to 31 days, week up to six months, then month) tells the agent what happens when granularity is left unspecified. It stops short of saying when to prefer this over compare_periods or the query-level 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/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: spelling variants are merged by default (group_variants=False disables it) and near-match URLs are substituted and listed in results, which an agent could not infer from 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?

Three short sentences, front-loaded with the purpose, then the variant-merging caveat, then the URL-matching rule. Slightly awkward final clause ('and listed') but no 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?

An output schema exists, so return values need not be described, and the two most consequential parameters are covered. Still, six unspecified parameters and no guidance on period/window semantics leave the definition only adequately complete for a 9-parameter analytics tool.

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 0% across 9 parameters, so the description carries the burden. It usefully documents page_url matching behavior and the group_variants toggle, but leaves days, level, limit, search_type, start_date and end_date entirely unexplained.

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+resource: 'Which queries send traffic to one page' clearly defines a queries-for-a-page report. It implicitly distinguishes from the inverse sibling pages_for_query, though it never names it explicitly.

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?

Explains how to supply page_url (exact URL, with substring fallback so paths like /blog/ work), which is practical invocation guidance. However, it never says when to use this tool versus pages_for_query or query_search_analytics, so sibling routing is left to inference.

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/idempotent/openWorld/non-destructive, so the safety profile is free. Beyond that the description discloses real behavioral nuance: sort_by is applied to the fetched rows while Google always returns top rows by clicks, data_state=all mirrors the UI, and grouping behavior differs by level. It does not discuss permissions or result size limits, but the added semantics are substantive.

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?

Purpose is front-loaded in two short sentences, then an argument list where nearly every line adds non-obvious semantics (spelling variants, sort vs. Google ordering, grouping). Dense, but little waste; the format is scannable rather than padded.

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 22-parameter tool with an output schema and rich annotations, the description supplies the parameter semantics and ordering caveats an agent needs. Remaining gaps (search_appearance filter, any limits on max_rows) are small relative to what is covered.

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 0% across 22 parameters, so the description carries the full documentation burden and mostly succeeds: it explains site_url formats, date-vs-days precedence, allowed dimension and search_type values, the multilingual/spelling-variant matching of query_filter, regex vs substring filters, ISO country codes, and the limit/max_rows split. Only search_appearance is undocumented as a filter, which is a minor omission against an otherwise thorough mapping.

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 concrete verb+resource (query Search Analytics rows) and positions itself as 'the general-purpose query tool', which implicitly contrasts with the many specialized siblings (top_terms, queries_for_page, striking_distance). It stops short of naming a sibling it is chosen over, so an agent must still infer the boundary.

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 general-purpose query tool' implies it is the fallback when no specialized sibling fits, which is usable guidance. But there is no explicit when-to-use/when-not statement and no named alternative, so the routing decision is left to inference.

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, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuine extra context: groups below min_variants are hidden, level=loose widens merging (spacing, accents, kana, Chinese variants), and source=history reads the local store rather than the API.

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?

Purpose is front-loaded in the first sentence, and the following sentences each earn their place by defining the grouping rule and the level/source behaviors. Dense but 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?

An output schema exists, so return values need not be described, and the read-only nature is annotated. However, with 11 parameters at 0% schema coverage and no usage/routing guidance, an agent still lacks enough information to pick sensible values for the undocumented parameters.

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 0% across 11 parameters, so the description must compensate and it only partially does: it explains level, min_variants and source semantics, but days, limit, max_rows, search_type, query_filter, start_date/end_date and site_url are left entirely to inference.

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?

Starts with a specific verb-and-resource framing ('Keywords that Search Console splits across several spellings, with their real combined totals') and details the grouping key, which distinguishes it from siblings like keyboard_mistypes and top_terms. It never names a sibling explicitly, so it stops short of a 5.

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 when-to-use / when-not-to-use guidance or named alternative. The description discusses level=loose and source=history as behavioral modes, which implies context, but an agent is not told when this tool should be chosen over top_terms or keyboard_mistypes.

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=false, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering the safety profile. The description adds that it forgets the cached client and re-signs in, which is useful behavioral detail beyond annotations, but it does not explain auth requirements, session effects, or what happens to other cached state.

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?

A single sentence that is front-loaded with the core action and includes only the necessary clarifying scope. 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?

The tool is simple, has no parameters, and an output schema exists, so return values need not be described. Annotations cover the safety profile. The description adequately conveys the action and when to use it, though it could mention whether reauthentication invalidates existing sessions or requires user interaction.

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 per the rubric the baseline is 4. The empty schema and 100% description coverage mean no parameter semantics are needed from the description.

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 and resource: 'Forget the cached client and sign in again.' It also clarifies the scope with '(switch Google accounts or scopes).' The sibling tools are all SEO/analytics operations, so this auth-related action is clearly distinguishable.

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 parenthetical '(switch Google accounts or scopes)' gives a clear trigger condition for when to use the tool. It does not list exclusions or alternatives, but the usage context is unambiguous for an 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 declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds two things the annotations do not: the write-gate requirement (GSC_ALLOW_WRITE=1) and the crucial scope clarification that removal only detaches the property from this account while Google retains the data. That materially changes how an agent should reason about the destructive flag.

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, front-loaded with the action and the gating constraint, with no filler. Every clause carries information 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?

An output schema exists, so return values need no prose, and the description covers the precondition and the data-retention nuance. The remaining gap is the undocumented site_url parameter, but for a single-argument tool the definition is nearly 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 description coverage is 0% for the single required parameter site_url, and the description never explains the expected URL format, whether trailing slashes or protocol variants matter, or whether it must match an existing listed property. With low coverage the description is supposed to compensate and it 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?

States a specific verb ('Remove') and resource ('a property from this account'), making the operation unambiguous and clearly distinct from add_property, list_properties, and get_property. It does not explicitly name when it differs from delete_sitemap, but the verb+resource pairing is precise enough to route correctly.

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 supplies a hard precondition ('needs GSC_ALLOW_WRITE=1'), which is real usage guidance, but it never says when to choose this over siblings like delete_sitemap or what happens if the property is still verified. Usage is implied rather than spelled out.

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 the read-only/idempotent safety profile, so the bar is lower, and the description adds genuinely non-obvious behavior: potential_clicks is defined as estimated extra clicks at position 5, and spelling variants are merged before querying. These are real preprocessing/semantic details beyond the structured fields, though filtering and result-shaping behavior remain unexplained.

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, zero filler, with the core scoping constraint (position range) front-loaded. Every clause carries information.

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?

An output schema exists, so return values need not be explained, but for a 13-parameter tool at 0% schema coverage the definition leaves most parameter behavior uncovered. It is adequate for understanding purpose and a couple of key behaviors, not for calling the tool precisely.

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 13 parameters and 0% schema description coverage, the description must carry the load but only incidentally touches two of them ('default positions 8–20' for min/max_position, 'real demand' for min_impressions). The other ten parameters (days, limit, source, dates, max_rows, with_pages, search_type, query_filter, site_url) are undocumented in both schema and description.

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 and resource ('queries ranking just off page one, default positions 8–20') with the opportunity-seeking framing. It is clear what the tool returns, though it does not explicitly differentiate itself from near siblings like low_ctr_opportunities or find_cannibalization.

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 quickest wins' implies the intent (opportunity discovery) but there is no explicit when-to-use, when-not, or named alternative among the many sibling analytics tools. Usage is left to inference.

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=false, idempotentHint=true, openWorldHint=true, destructiveHint=false, so safety and idempotency are covered. The description adds the operational enablement gate (GSC_ALLOW_WRITE=1), which is a genuine behavioral constraint not present in the annotations and is exactly the kind of auth/precondition context that earns credit.

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?

A single short sentence with the verb, resource, resubmit case, and precondition front-loaded; no filler. It is arguably too terse for a write tool, but nothing in it is wasted.

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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. What remains missing is any explanation of the two required parameters and the target site/property context, which is a meaningful gap for a mutation tool.

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 0% for two required parameters, so the description carries the full burden. It only gestures at 'a sitemap URL' and never explains what site_url means (property vs. sitemap host) or how the two relate, leaving the required site_url parameter entirely undocumented.

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+resource pair ('Submit (or resubmit) a sitemap URL') and the resubmit nuance implies the upsert behavior an agent needs. It does not name sibling tools (delete_sitemap, get_sitemap, list_sitemaps) to disambiguate, so it falls short of a 5.

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 parenthetical '(needs GSC_ALLOW_WRITE=1)' gives a concrete precondition for calling the tool, which is real usage guidance. However, there is no when-to-use vs alternatives framing and no statement of when not to call it relative to delete_sitemap or list_sitemaps.

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?

Adds substantial context beyond annotations: the 45-second execution window, incremental resume behavior, skip-vs-refresh policy tied to finality/emptiness, and the 16-month retention rationale. Annotations only give readOnly=false, idempotent=true, openWorld=true, destructive=false.

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?

Front-loaded with the core action, then the retention rationale, then skip/refresh policy, then the continuation workflow. Dense but each clause carries operational information; slightly long but not wasteful given 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?

For a 7-param write tool with an output schema present, the description covers the critical behavior an agent needs: resumability, time budget, what is skipped vs refreshed. Omits coverage of four parameters but return shape is handled by 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 coverage is 0%, so the description must carry the load. It explains 'dimensions' defaults to query,page with country/device as expansion (with 'more rows' tradeoff) and implicitly covers 'days' via the 16-month note, but leaves end_date, start_date, search_type, and refresh_provisional undocumented.

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 ('Copy'), resource ('Search Analytics rows'), and destination ('local SQLite history'). Distinguishes itself from siblings like query_search_analytics (live API query) and history_* (read from local history) by being the ingest path.

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 says when to use it ('keeps data past 16 months'), what gets skipped ('Days already stored and final'), and names the CLI alternative with its advantage ('no time limit; put it in cron'). The call-again-to-continue loop is spelled out.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about tokenization via jieba/fugashi/pythainlp, a script-aware fallback, and merging terms across spellings, but it does not disclose auth requirements, rate limits, or data freshness handling.

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 first sentence front-loads the tool's purpose, and the follow-up sentence gives relevant language-processing context in a compact form. The pip-install detail is somewhat implementation-oriented but still brief and not excessively 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?

With 9 parameters at 0% schema coverage, the description omits nearly all parameter semantics, leaving an agent unable to know what top, days, source, or query_filter control. An output schema exists, so return values need not be explained, but the input side is substantially incomplete for a moderately complex tool.

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 0% across 9 parameters, and the description does not mention any parameter names, meanings, formats, or defaults. For a tool with top, days, source, dates, max_rows, search_type, query_filter, and site_url, the description provides no compensating semantic detail.

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 identifies the tool's output as 'most demanded words across all queries,' which is a clear resource and scope, and the name top_terms reinforces it. It distinguishes itself from generic search analytics tools by noting language support for Chinese/Japanese/Thai, but it does not explicitly state a verb like 'extract' or 'list' or name a sibling 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 description gives no explicit guidance on when to use top_terms versus siblings like query_search_analytics or query_variants. The language-support notes imply it is useful for non-space-delimited languages, but that is not framed as a usage condition or alternative selection rule.

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