Diagnose index coverage

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

Annotations provide readOnlyHint=true, and the description consistently describes read-only operations. It adds meaningful behavioral context beyond the annotation: it reads from sitemaps, inspects URLs, groups by coverage state, and produces plain-language guidance. No contradiction exists.

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 with no wasted words. The core purpose is front-loaded, followed by operational detail and then a rationale that aids selection. Every sentence earns its place.

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

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

The description, rich parameter schema, and read-only annotation together cover the tool's purpose, input selection, behavior, and output shape at a useful level. An output schema is absent, but the description gives enough return expectation by mentioning grouping by coverage state and guidance. Minor detail about exact response format is not critical 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 100%, so the schema already documents all five parameters. The description reinforces the sitemap-vs-explicit-list behavior for `urls` and `sitemapUrl`, but adds no new parameter meaning beyond what the schema already states.

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 action and resource: it 'Explains why pages are or are not indexed' and details the mechanism ('Reads URLs from the site's sitemap', 'inspects each one', 'groups the results by coverage state'). It also distinguishes itself by noting it reconstructs the Pages report not available as a bulk API.

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

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

The description clearly communicates when to use it: for batch index-coverage diagnostics via sitemap or explicit URL list, especially when the Pages report is needed outside the UI. It does not explicitly name sibling alternatives or state exclusions, but the bulk-report framing provides strong usage context.

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