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

The readOnlyHint annotation indicates no destructive side effects, and the description adds useful non-obvious behavior: citation locators are position-based h2/h3 ID fragments and are only valid within the producing snapshot. This goes beyond the annotation, though it does not mention output size, pagination, or error 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 concise sentences with the main action front-loaded and a relevant caveat afterward. No filler, redundant schema restatement, or unnecessary detail.

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?

Though the core purpose is stated, the absence of an output schema and the 0% parameter coverage leave important context missing: how topic and fields filter results, what an 'approved source page' is, and how the list relates to snapshots. The citation-locator caveat is useful but does not make the description 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 0% and the description does not explain any of the three parameters (limit, topic, fields). It does not compensate for the missing parameter descriptions, leaving an agent to infer semantics solely from names and the fields enum.

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 clear action (List) and object (approved source pages) and distinguishes this from sibling content-retrieval tools like public-evidence_get_document and public-evidence_search_passages. However, 'approved source pages' is not fully defined, and the relationship to evidence snapshots is implied rather than explicit.

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 does not state when to prefer this tool over siblings or when not to use it. It implies an enumeration/browsing use case but gives no explicit guidance, alternatives, or conditions such as 'use this before searching passages.'

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