Check index coverage

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

The description contradicts the annotations. It presents this as a read-only metadata check ("Check authoritative indexing-coverage metadata", "Returns coverage status") and even notes the signal is best-effort and not a completeness guarantee. However, annotations declare destructiveHint: true and openWorldHint: false. The destructive flag implies side effects, and openWorldHint false contradicts the "not a completeness guarantee" caveat. These are serious inconsistencies that undermine trust.

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 dense but well-organized into four sentences. It front-loads the core purpose, then provides usage guidance, return-value summary, caveat, and runtime requirement. Every sentence adds unique value without redundant filler, and the length is appropriate for the tool's 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?

Given the complexity (5 params, no output schema), the description covers most operational needs: how to use, when to use, what is returned, and a critical caveat. It even names a specific status value (indexed_no_recorded_gap). However, it omits explanation of pagination (scope_limit/scope_offset) and the meaning of project, and the annotation contradictions weaken overall contextual completeness.

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 only 40% (paths and scopes have descriptions, project/scope_limit/scope_offset do not). The description adds important context about paths and scopes, such as requiring at least one and runtime rejection if both omitted. However, it does not explain project, scope_limit, or scope_offset, leaving pagination and required project identification undocumented. It partially compensates but not fully.

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 the tool's purpose: "Check authoritative indexing-coverage metadata for exact repository-relative paths and bounded path scopes." It identifies the specific verb (check), resource (indexing-coverage metadata), and scope (paths/scopes), which distinguishes it from sibling tools like search_graph or index_repository.

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 provides strong usage guidance: "Use this after graph discovery for every cited or operated-on file" and "use scopes before negative/exhaustive claims because fully skipped files cannot appear in normal graph results." It explains when to use scopes vs paths, but does not explicitly name alternative tools or state when not to use this tool, 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.