Read an indexing request

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

Annotations already cover readOnly, non-destructive, closed-world, so the description's added value is semantic: eta_text applies only while the request is open, and a closed request with status 'requested' means only that the click happened, not that indexing succeeded. That interpretation guidance is genuinely beyond structured fields, though it doesn't address lookup-miss 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 sentences with no filler; the returned-field summary comes first and the check_url disambiguation second. Phrasing like 'once the extension performed it' is terse and assumes some context, 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?

With one required parameter, no output schema, and annotations covering safety, the description is complete enough: it enumerates the meaningful return concepts and their conditions. Remaining gaps are minor—unnoted behavior for an unknown or stale request_id.

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% for the single request_id parameter, including UUID format and pattern, so the schema does the documentation work. The description adds no syntax or sourcing detail (e.g., where a request_id comes from) beyond that baseline.

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 the resource (one indexing request) and specifies exactly what is returned: status, queue position, and ETA in eta_text while open, plus the Search Console response once performed. This separates it from check_url, which handles post-indexation questions. It doesn't explicitly contrast itself with list_indexing_requests beyond the singular 'One indexing request'.

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 routes a related but distinct question explicitly: 'whether Google indexed the page is check_url's answer,' telling the agent not to expect indexation truth from this tool. The condition of use (read a single request, especially an open one or a closed one with status requested) is clear, though no when-not rule or prerequisite is stated outright.

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