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

Annotations already carry the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds non-obvious operational context: URL Inspection reads consume Search Console inspection quota. That quota disclosure is real value beyond annotations; it does not, however, discuss latency or failure modes for the expensive multi-fetch paths.

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 one-line purpose before the enumerations, and the closing sentence handles routing efficiently. The middle enumeration sentence is long and dense, but each listed item maps to a distinct output section rather than being 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?

Output schema exists, so return-shape detail is not required, yet the description still signals what the agent will get and how costly the optional paths are. Scope, read-only nature, quota implications, parameter caps, and the sibling alternative are all present, leaving no material gap for a high-complexity, 7-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 coverage is 100%, so 3 is the baseline and the schema already documents limit/offset/dates. The description goes further by explaining intent for two parameters — inspect is capped at 20 and should only be raised when index state is needed, contentPages is capped at 25 and defaults to 10 — which adds decision-level meaning the schema's terse ranges do 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?

Opens with a specific verb+resource+scope: 'Site-wide search coverage for one owned site', then enumerates the concrete artifacts it returns (sitemap vs. impressions gaps, submitted sitemaps, URL Inspection status, duplicate/short pages). It explicitly contrasts itself with get_seo_evidence, so an agent can separate the two 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?

Names the alternative and the condition that selects it: 'Use get_seo_evidence for one page's queries, HTML or analytics', implying this tool is for site-wide coverage. It also gives per-parameter usage rules ('set it only when index state is needed' for inspect). It stops short of stating a full when-not-to-use boundary beyond 'no audits or edits'.

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