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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-derivable behavior: the resulting property is created unverified and no data flows until out-of-band verification occurs, which is important operational 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 with no filler; the core action is front-loaded and the caveat follows immediately. 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?

An output schema exists, so return values need no explanation, and annotations carry the idempotency and safety profile. The description supplies the key post-condition (unverified state), leaving only minor gaps such as error behavior for already-registered properties.

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

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

Schema description coverage is 100% and the single site_url parameter is documented in the schema with both accepted formats ('sc-domain:example.com' and a URL prefix). The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Add a property to this account'), making it instantly distinguishable from list_sites, get_site, and delete_site by verb alone. It does not name a sibling explicitly, but the create counterpart role is unmistakable.

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 crucial precondition that the property starts unverified and that ownership must be confirmed in the Search Console web interface before data is available, which effectively tells an agent when this call is (and isn't) enough on its own. It stops short of naming alternatives or exclusions, so it falls just short of a 5.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the things an agent can't get from structured fields: local progress persistence with resume semantics, the restart-resets-saved-audit behavior, the 2,000-inspections-per-day quota, the 10-at-a-time concurrency and ~30s cost for 50 URLs, and which URLs are prioritized (new first, then stale >14 days). This is unusually rich operational 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?

Purpose is front-loaded in the first sentence, followed by resume/quota mechanics; there is little filler. It is slightly dense, and the run-on listing of reported categories (index status with fixes, canonical conflicts, no-impression pages, missing pages) leans into return-value detail that the output schema could carry.

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 an output schema that documents the return shape and full schema coverage on all 8 parameters, the description supplies exactly the missing pieces: why the audit is sitemap-driven, that it is resumable and quota-limited, and that issue mode is report-only. An agent can decide whether to call it, and how to call it repeatedly, without further information.

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

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

Schema description coverage is 100%, and each parameter already carries detailed text (issue, start, inspect, restart, examples, site_url, fetch_pages, sitemap_url), so the schema does the heavy lifting and a baseline 3 applies. The description adds framing around the two operational modes and the daily quota but no additional parameter-level syntax or format guidance.

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

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

The description opens with a specific verb+resource+method: a full indexing audit of a property, rebuilt from its sitemaps because Google's API omits the Page indexing report's URL lists. That method statement separates it cleanly from siblings like inspect_url, batch_inspect_urls and list_sitemaps, which do single/low-volume lookups or only enumerate sitemaps.

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

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

It gives clear operating context: call again to continue the audit, today or on later days, with a hard ceiling of 2,000 inspections per property per day, and it explains that passing an issue key switches to a pure reporting mode where 'nothing new is inspected.' It stops short of explicitly naming alternatives (e.g., inspect_url for a one-off URL), so a routing decision between siblings still needs 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?

Beyond the readOnlyHint=true and openWorldHint=false annotations, the description discloses genuinely useful behavior: per-URL failure reporting, partial completion when the daily quota runs out, and that skipped URLs are listed for later retry. It stops short of saying whether verdicts are cached or how long a quota reset takes.

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 sentences, zero filler, and the capability and its limit are front-loaded ahead of the edge-case behavior. Every clause carries information an agent would otherwise have to guess.

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-shape explanation is rightly omitted, and the description covers the quota and partial-failure cases an agent must handle. It is slightly incomplete in not clarifying that all URLs must belong to the single required site_url property, which affects how the batch should be constructed.

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

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

Schema description coverage is 100%: maxItems=50, the site_url property-resolution rules, and the BCP-47 language_code default are all documented in the schema. The description's 'up to 50 URLs' only restates maxItems, adding no syntax or format detail beyond the structured fields, so the baseline 3 applies.

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

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

States a specific verb (inspect) and resource (URLs) plus scope: batch, up to 50, concurrent, summarizing index verdicts. It never names the sibling inspect_url, so an agent must infer the batch-vs-single distinction from the name and the '50 URLs' limit.

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 50-URL concurrency and quota-exhaustion notes imply bulk use, but there is no explicit statement of when to prefer this over inspect_url, nor any exclusion such as single-URL checks or URLs belonging to different properties.

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 and openWorldHint=false, so safety is covered. The description adds real behavioral value beyond that: it defines the return shape and, crucially, the sign convention that a negative position change means improved ranking — a non-obvious detail an agent would otherwise misinterpret. It stops short of noting pagination or the effect of data_state on the comparison.

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 sentences, front-loaded with the core purpose, followed by the one caveat an agent is most likely to get wrong. Every clause earns its place with 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?

With an output schema present, return values need not be explained, and the 12-parameter schema is 92% self-documenting. The description supplies the non-obvious semantic notes (equal-length windows, negative position change) that the schema cannot express, so it is complete enough for correct invocation.

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

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

Schema description coverage is 92%, so the schema already documents nearly every parameter with defaults and enums. The description adds little parameter-level detail beyond the implied equal-length requirement for the current/previous windows, which is the baseline 3 case where the schema carries the load.

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

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

The description states a specific verb and resource — comparing search performance between two equal-length periods — and even sketches the output shape (totals plus per-key breakdown with absolute and percent changes). It is clear on its own, but it never names or contrasts against siblings like query_search_analytics or explain_change, so the agent must 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?

Usage is implied by the framing (a period-over-period comparison) and the 'equal length' constraint hints at when it applies. However, there is no explicit when-to-use/when-not guidance and no routing to explain_change for single-change analysis or to query_search_analytics for a single period, leaving the agent to guess.

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 declare destructiveHint=true, but the description adds meaning the annotations cannot convey: it removes access for this account only and does not delete the site or other users' access. That materially reframes the blast radius of a destructive call, plus it requires user confirmation.

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 action and scope, then the access caveat, then the confirmation requirement. Nothing is 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?

With rich annotations, an output schema present, and a fully documented single parameter, the description supplies exactly the extra context an agent needs: scope of deletion and the confirmation requirement. No critical gap remains.

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

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

Schema coverage is 100% and the single site_url parameter is fully documented in the schema, including the pointer to list_sites. The description adds no further parameter syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Remove a property from this account') and immediately scopes what is being removed, distinguishing it from write/query siblings like add_site and list_sites. An agent knows exactly what this does 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?

Gives an explicit precondition ('Confirm with the user first'), which is actionable usage guidance for a destructive operation. It does not name alternatives or state when-not-to-use (e.g. when the caller lacks admin rights), so it falls short of a full 5.

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

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

Annotations already mark this destructive and idempotent, but the description adds non-obvious behavioral facts the agent could not derive from them: Google may still retain the URLs and the sitemap file on disk is untouched. It also flags the required user confirmation, which goes beyond the annotation hints.

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

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

Two short sentences, front-loaded with the action and followed by the two facts an agent actually needs. No filler or restatement of the tool name.

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 schema fully covers the two parameters. The description supplies the remaining operational context (scope of deletion, confirmation requirement) for a destructive 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 100% and both parameters (site_url, sitemap_url) are already documented with format examples in the schema. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Remove a sitemap from Search Console'), which cleanly separates it from the sibling read/submit tools (list_sitemaps, get_sitemap, submit_sitemap). The added clause about what removal does and does not mean sharpens the purpose further.

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

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

Explicitly instructs 'Confirm with the user first,' which is meaningful guidance for a destructive operation. It stops short of naming a when-not condition or an alternative path (e.g., when to leave an outdated sitemap alone), so it is strong but not exhaustive.

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 and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the decomposition it performs (impressions loss vs CTR loss, update overlay) and the default comparison window of the last 28 days of final data versus the prior 28.

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, front-loaded with the question the tool answers, then the mechanics, then the default. Dense but free of filler; appropriate weight for a 12-parameter tool.

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 description covers purpose, decomposition, and defaults. It is thin only on practical constraints an agent might want, such as cost/rate behavior implied by fetch_limit up to 25000 and the default search_type.

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 already 92%, which sets a baseline of 3. The description adds meaning on top by spelling out the default period pairing and the final-data window that governs current_end/previous_end, and by clarifying that the split covers page, query, country, device and search appearance.

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 concrete verb and resource — explaining why traffic moved between two equal-length periods — and enumerates the concrete outputs (per-dimension splits, impressions-vs-CTR decomposition, Google updates). It never names or contrasts against the sibling compare_periods, so an agent must infer the boundary between 'explain the change' and 'compare periods'.

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

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

Usage is strongly implied by the framing question ('why did traffic go up or down?') and the default window is stated, but there is no explicit when-to-use/when-not guidance and no named alternative among the many query_* and compare_periods siblings.

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 and openWorldHint=false, so the safety profile is covered. The description adds the fact that the response includes the calling account's permission level, which is useful context, but because an output schema exists the return fields are already documented. This meets the lower bar annotations set.

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 zero filler, front-loaded with the verb and the key noun phrase. Nothing to trim.

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

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

With one fully documented parameter, readOnly annotations, and an output schema, the description covers everything needed to invoke the tool correctly. The only gap is error/not-found behavior, which is minor.

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

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

Schema description coverage is 100% and the single site_url parameter is thoroughly documented there, including domain vs URL-prefix formats and resolution of bare domains. The description adds no parameter-level meaning beyond that, so baseline 3 applies.

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

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

The description gives a precise verb and resource ('Get one property's exact site_url, type and permission level'), and the singular 'one property's' implicitly contrasts with the sibling list_sites. It does not name or explicitly contrast with any sibling, so it stops 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?

There is no when-to-use statement, no mention of alternatives such as list_sites for enumeration or add_site/delete_site for mutation, and no note about behavior when the property is not accessible. Only the returned fields hint at the intended use (checking type/permission), which is weak implied guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — no handling of a missing sitemap, no error behavior, no indication of what status values mean.

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 six-word fragment with no wasted words, but it errs toward under-specification rather than tight structure. There is nothing to front-load because almost nothing is said.

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, and the schema fully documents both parameters. However, a status-retrieval tool paired with list/sumbit/delete siblings would benefit from at least a sentence of routing guidance, which is absent.

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

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

Schema description coverage is 100%, with site_url and sitemap_url both well documented (property formats, resolution rules, example sitemap URL), so the schema carries the full burden. The description adds no syntax or meaning beyond it, which is the baseline 3.

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 (sitemap) and the specific scope ('one submitted sitemap'), which distinguishes it from the sibling list_sitemaps that returns many. It is a noun phrase rather than a verb-led sentence, but an agent can still tell what it does.

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 when-to-use guidance, no prerequisites, and no explicit routing to or away from alternatives such as list_sitemaps or submit_sitemap. The single/plural distinction is the only implicit hint.

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 and openWorldHint=false, and the description adds real behavioral context: the data is Google's cached indexed view, not a live fetch, so results may lag the current page state. It does not disclose quota/rate-limit behavior or that the property must be verified/accessible, leaving some operational context unstated.

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 sentences, no filler: the first front-loads the scope and the returned facets, the second immediately clarifies the data's nature. The dense enumeration is all substantive content rather than 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?

For a read-only, single-URL inspection tool with a full output schema and 100% parameter coverage, the description covers purpose, scope, and the key interpretive caveat (indexed view vs live test). An agent can select and call it correctly with no remaining ambiguity.

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

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

Schema description coverage is 100%, with url, site_url (including the sc-domain: vs URL-prefix formats and resolution rules) and language_code all documented in the schema. The description adds nothing about parameter format or interaction, so this is the baseline case where the schema does all the work.

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 ('Google's index status for one URL') and enumerates exactly what the response covers: index status, why not indexed, last crawl, canonicals, robots.txt/fetch state, sitemaps, rich results. The 'one URL' scoping implicitly separates it from batch_inspect_urls and audit_indexing, but no sibling is named, so differentiation relies on inference.

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 closing sentence gives a clear usage boundary: this is Google's indexed view rather than a live page test, which tells the agent when this tool is the right data source. It stops short of naming alternatives (e.g. batch_inspect_urls for multiple URLs) or stating prerequisites such as a verified property in list_sites.

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 safety profile (readOnlyHint=true, openWorldHint=false), so the description adds value by disclosing the two-step workflow: this call enumerates named appearances and a second tool decomposes them. It also notes that returned names are what the follow-up consumes. It does not mention pagination, row limits, or quota 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 sentences, zero filler, with the enumeration purpose front-loaded and the required next step immediately after. Nothing could be cut without losing routing 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 read-only listing tool with an output schema that documents returns and annotations that cover safety, the description supplies the missing workflow context. The only gap is search_type, the one parameter with no schema description and no mention here, which leaves an ambiguity for non-default search types.

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

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

Schema description coverage is 80% with well-documented date, site_url, and data_state parameters, so the schema carries the semantics. The description adds no parameter detail whatsoever — nothing about search_type choices, date defaults, or property formats. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('list the search appearances ... the property had') and immediately defines the term with concrete examples (rich results, VIDEO, REVIEW_SNIPPET), plus what it returns (clicks and impressions). It also distinguishes itself from the query_* analytics siblings by scoping to result features rather than overall search performance.

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 frames itself as 'step one' and names the follow-up tool and how to invoke it ('call query_search_appearance with one of the names'). However, it gives no guidance on when to prefer the other analytics siblings (query_search_analytics, query_image_analytics, etc.) for aggregate performance data, leaving that exclusion 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=true and openWorldHint=false, so the safety profile is covered. The description adds a useful behavioral note that only 'submitted' sitemaps are reported and that processing-pending state is surfaced, but its enumeration of status fields largely overlaps what an output schema would already document.

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 zero filler; the resource comes first and the returned status categories follow compactly. Nothing in it is redundant 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?

For a read-only two-parameter list tool with an output schema and fully described parameters, the definition is close to sufficient – the agent knows the resource, the required input, and roughly what comes back. The only real gap is guidance on when this beats get_sitemap, which keeps it short of a 5.

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

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

Schema description coverage is 100% – both site_url and sitemap_index are fully documented in the schema, including property-resolution semantics and index filtering. The description adds no parameter-level information beyond that, so the baseline 3 applies.

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

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

The description states a specific verb and resource (list submitted sitemaps) plus the scope of the listing (status, errors, warnings, URL counts), so the agent knows exactly what it returns. It does not, however, distinguish itself from the sibling get_sitemap, which an agent could plausibly confuse with this 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?

Usage is only implied: 'list submitted sitemaps' suggests a survey-all-sitemaps-for-a-site scenario, but the description never says when to reach for this versus get_sitemap, submit_sitemap, or delete_sitemap. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: it discloses the return fields (site_url, permission level) and its role as a prerequisite for all sibling tools.

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 sentences, no filler, with the resource and returned fields front-loaded and the critical ordering instruction placed last for emphasis.

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 documentation is not required; the description still previews the key fields. For a zero-parameter read-only listing tool, nothing an agent needs is missing.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There are no parameters whose meaning the description could or should elaborate.

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 ('List every Search Console property this account can access') and names the two returned fields (site_url, permission level). It is clearly distinguishable from the singular sibling get_site.

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

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

Explicitly instructs 'Call this first: every other tool needs a site_url,' which is a precise when-to-use directive and implicitly excludes it from the query/inspect/sitemap workflows that depend on it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: data availability is limited to sites appearing in Discover feeds, and certain metrics simply do not exist. Pagination and data-state behavior are left to the schema rather than the description.

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 sentences with zero waste. The positive statement of what the tool returns is front-loaded, and the limiting caveats follow. Nothing is repeated from the schema or annotations.

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 an output schema present and 100% parameter coverage, the description only needs to carry the Discover-specific gotchas, which it does (no query/position/device data, feed-only coverage). What remains uncovered — aggregation_type behavior and paging — is fully described in the schema, so nothing critical is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented in detail by the schema. The description only restates the available grouping dimensions, adding no syntax, default or constraint information beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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 first sentence names the exact resource (Google Discover performance) and enumerates the metrics and grouping dimensions (clicks, impressions, CTR by page, country or date). An agent can distinguish it from query_search_analytics by the resource name alone. It stops short of explicitly contrasting itself with the other query_*_analytics siblings.

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

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

The second sentence gives strong negative guidance: Discover has no query, average-position or device data, and only covers sites that appear in Discover feeds — which steers the agent away from this tool when those dimensions are needed. It never names an alternative sibling (e.g. query_search_analytics) to use instead, so routing requires 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=true and openWorldHint=false, so safety is covered. The description adds a genuinely useful behavioral constraint not in annotations or schema: Google News carries no query or average-position data, which shapes what the agent can ask for. It does not discuss paging or data freshness, but the schema covers those.

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

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

Three tight sentences, front-loaded with scope and metrics before the disambiguation and the negative constraint. Every sentence carries distinct information; nothing is redundant.

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. For a 9-parameter, 100%-covered read tool, the description supplies the scope, the metric limitations, and the sibling routing rule — everything an agent needs to select and invoke it correctly.

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

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

Schema description coverage is 100%, so every one of the 9 parameters (including the nuanced aggregation_type and data_state) is already documented in the schema. The description adds no parameter-level detail beyond the metric/dimension list, so the baseline 3 applies.

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

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

States a specific verb+resource (Google News performance) and enumerates the metrics returned (clicks, impressions, CTR) plus the dimensions available (page, country, device, date). It explicitly names the sibling it is not, query_news_tab_analytics, so an agent can disambiguate the two news tools without opening either 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 an explicit routing rule: 'For the News tab in Google Search, use query_news_tab_analytics,' with the condition that selects the alternative. It also pre-empts wrong usage by stating Google News reports no queries and no average position, so the agent knows not to expect those metrics.

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 and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior the annotations lack: results are in Pacific Time, capped at ~10 days, and recent hours are incomplete with first_incomplete_hour marking the boundary.

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

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

Three tight sentences, front-loaded with the scope, then the use case, then the data-freshness caveat. Every sentence earns its place with 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?

With an output schema present and annotations covering the safety profile, the description only needs to add the time/window/freshness context, which it does. It could say slightly more about how the dimensions parameter interacts with hourly grouping, but that gap is minor.

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 88%, so the schema documents parameters itself. The description reinforces the 10-day window that constrains start_date but adds no per-parameter syntax or semantics beyond what the schema and its enum/description already provide. Baseline 3 applies.

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

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

States a specific verb (query) and resource (hourly search analytics) with the exact granularity (per hour), timezone (Pacific Time), and window (~10 days). This distinguishes it from the daily-grain sibling query_search_analytics without needing to open either 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?

Gives explicit usage contexts: spotting same-day spikes and comparing today to the same day last week. Clear when-to-use guidance, but it never names the alternative tool (e.g. query_search_analytics) to steer the agent away when daily granularity suffices.

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 and openWorldHint=false, so safety is covered. The description adds no behavioral context beyond that: nothing about row-limit ceilings, paging, data freshness, or how filters compose. It is essentially a purpose statement, not a behavioral disclosure.

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 dense sentence with the resource front-loaded ahead of the metric and dimension lists. No filler sentences, though the list-heavy construction is slightly run-on and the absence of a leading verb makes it read as a label rather than an instruction.

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, and the input schema carries all parameter semantics. What is missing is the routing layer: with eight sibling analytics tools, the description never states when image analytics is the right pick. For a nine-parameter tool it is minimal but not incomplete on the mechanics.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters thoroughly (site_url resolution, date defaults, data_state semantics, dimension rules). The description echoes the usable dimensions, which adds marginal confirmation but no syntax or constraint detail beyond the schema. Baseline 3 applies.

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

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

The description names a specific resource (Google Images and the Images tab of Search) and enumerates the metrics returned (clicks, impressions, CTR, average position) broken down by query, page, country, device or date. That is enough to separate it from query_search_analytics or query_video_analytics on the basis of scope, even though no sibling is named explicitly and the sentence lacks a leading verb.

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 resource restriction to Google Images tells the agent when this tool applies, but there is no explicit 'use this instead of X when Y' statement, no prerequisites, and no exclusions against the sibling analytics tools. Adequate but with clear gaps.

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 and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that — e.g., data freshness/lag handling, pagination behavior, or the effects of combining multiple filters — even though the 'final' vs 'all' distinction and daily row limits are real operational traits. With annotations carrying the safety burden, a 3 is appropriate.

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 sentences, each earning its place: the first defines the data and metrics, the second does the sibling routing. The most important content (what the tool returns) is front-loaded, 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?

With a full output schema, 100% schema description coverage, and annotations covering the safety profile, the description only needs to establish scope and sibling routing, which it does cleanly. Nothing an agent needs to select or invoke the tool correctly is missing.

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

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

Schema description coverage is 100%, so every parameter (filters, dates, dimensions, aggregation_type, data_state, paging) is already documented with enums and defaults in the schema. The description contributes no additional parameter meaning beyond naming dimension categories. Baseline 3 is correct when the schema does all the heavy lifting.

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 first sentence names the specific data surface (News tab of Google Search) and enumerates the returned metrics plus available breakdown dimensions, so the agent knows exactly what the tool produces. It also explicitly distinguishes itself from query_google_news_analytics, which covers news.google.com and the Google News app. This is a specific verb+resource+scope that no sibling duplicates.

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 routes the agent away from this tool for news.google.com/Google News app use cases, naming the correct alternative. It does not, however, explain the boundary against query_search_analytics or when News-tab data is the right choice versus general Search performance, so the guidance is clear but not exhaustive.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses two genuinely useful traits: output ordering ('rows are sorted by clicks') and pre-flight validation ('invalid combinations are rejected with an explanation before Google is called'), which tells the agent bad calls fail cheaply. It says nothing about quotas or rate limits, but the safety profile is otherwise covered by annotations.

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

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

Four sentences, front-loaded with what the call returns, and every sentence carries content (metrics, sort order, validation behaviour, sibling routing). The closing sentence about 'the matching query_*_analytics tool' is slightly abstract and could name the tools more directly, but 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?

With an output schema present and 100% schema coverage, the description needs only to frame purpose and edge behaviour, which it does (sorting, rejected combinations, surface routing). The remaining gap is that dimension/aggregation constraints are left entirely to the schema rather than reinforced, which is acceptable but leaves the description thin for a ten-parameter 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 100%, so the schema already documents all ten parameters in detail, including dimension combinations and search_type constraints. The description only summarises 'grouped by dimensions and filtered' and the default sort, so it adds little beyond the structured fields; baseline 3 applies.

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

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

The first sentence names the exact resource (the Performance report) and the metrics it returns (clicks, impressions, CTR, average position), plus the grouping/filtering operation. The final sentence routes the agent away from the query_*_analytics siblings for Discover/Images/video/News surfaces, so an agent can tell which tool applies without opening a 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 explicitly states when to pick a sibling instead: for Discover, Images, video, Google News or the News tab, use the matching query_*_analytics tool. It gives no guidance against the other query variants (query_hourly_analytics, compare_periods, explain_change, query_search_appearance), so the routing is clear but not exhaustive.

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 and openWorldHint=false, so the safety profile is covered. The description adds the workflow sequencing context but says nothing about freshness, pagination behavior, or quota concerns beyond what the schema's data_state field already documents. Adequate, not rich.

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

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

Two tight sentences with zero waste. The purpose and the prerequisite are both front-loaded and 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 an output schema and annotations already present, the description needn't explain return values. It supplies the one thing the schema cannot: the sequencing dependency on list_search_appearances. Slightly light on how it relates to the sibling analytics tools, but essentially 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 90%, so the schema already documents nearly every parameter (filters, dates, pagination, data_state, dimensions). The description echoes the breakdown dimensions but adds no format or syntax detail beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb+resource ('performance of one search appearance') and the breakdown dimensions, which clearly differentiates it from keyword-level siblings like query_search_analytics. It stops short of explicitly naming the sibling it differs from, so an agent must infer the distinction.

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?

Positions the tool as 'step two' in a workflow and gives the prerequisite: 'Get the appearance name from list_search_appearances.' That routes the agent to the correct source for the required 'appearance' argument. No explicit when-not guidance or mention of the sibling analytics tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a scope/attribution rule (where video impressions are counted), which is useful, but says nothing about data latency or result-size behavior beyond what the annotations and schema already 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?

Two sentences, both earning their place: the first front-loads what the tool returns and by which dimensions, the second front-loads the scope boundary. No filler, no restatement of the title.

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, and the schema covers parameter semantics and enum constraints. The description supplies the one thing structured fields cannot – the reporting-scope boundary – leaving only minor gaps around data freshness, which data_state already handles.

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

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

Schema description coverage is 100%, so every parameter (site_url resolution rules, date defaults, data_state, aggregation_type, row paging) is already documented in the schema. The description adds no parameter-level detail beyond that, which is the baseline 3 case when the schema does the heavy lifting.

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 (Videos tab performance in Google Search) with the exact metrics returned (clicks, impressions, CTR, average position) and the breakable dimensions. The closing sentence distinguishes it from web-search reporting, so an agent can tell it apart from query_search_analytics without opening either 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 negative scope statement ('Video results shown on the main web results are counted under web search, not here') tells the agent when this tool is the wrong choice, which is real routing value. It stops short of naming the alternative tool explicitly, so it is clear context rather than full when/when-not/alternatives guidance.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so 'Safe to repeat' largely restates structured data. It does add real behavioral context by explaining the side effect is triggering a Google fetch, which the annotations do not encode. No mention of prerequisites such as the site needing to be a verified property.

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, no filler, with the action stated first and the idempotency note second. 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?

Output schema exists and annotations cover the safety profile, so the description need only carry purpose and repeatability, which it does. It is slightly thin on prerequisites and cross-tool routing for a tool sitting in a 22-tool sitemap/site family.

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

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

Schema description coverage is 100% and both parameters carry their own descriptions (exact site_url from list_sites; full sitemap URL with an example). The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (submit/resubmit) and resource (sitemap), plus the effect: 'so Google fetches it.' That separates it cleanly from list_sitemaps, get_sitemap, and delete_sitemap by verb. It does not name any 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?

'(or resubmit)' and 'Safe to repeat' imply the retry/resubmit use case, which is useful context. However there is no explicit when-to-use guidance or routing (e.g., when to prefer submit_sitemap over add_site or how it relates to list_sitemaps), so usage is only implied.

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