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

Annotations already establish readOnly and idempotent behavior. The description adds useful behavioral context beyond those annotations: results are bounded excerpts rather than full source text, citations are returned, pagination is tied to a generation-bound cursor, and source text must be treated as untrusted data. This is meaningful disclosure without contradicting the annotations.

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 three short sentences with no filler. The search scope and criteria are front-loaded, the return shape follows immediately, and the untrusted-data warning earns its place as a security-relevant note.

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 seven parameters, zero schema descriptions, and no output schema, this description is reasonably informative but not fully complete. It communicates the core purpose and return shape, but an agent still lacks enough guidance on pagination mechanics, type filtering, and when to prefer this tool over get_evidence or list_changes.

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%, so the description must compensate. It maps 'words' to the query parameter, 'source' to the types concept, 'verified author' to author, and 'topic' to topic. However, it leaves the cursor/generation semantics only partially explained and does not clarify the limit or types parameters in detail, so the compensation is incomplete.

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 ('Search') and resource ('published Roboto evidence'), then specifies the search dimensions: words, source, verified author, or topic. The return characteristics (bounded excerpts, source citations, generation-bound cursor) clarify what kind of results this produces and distinguish it from get/list/build siblings.

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 gives clear context for when this tool is appropriate: finding published evidence by free-text words, source, author, or topic. It does not explicitly name alternatives or exclusions such as 'use get_evidence for exact IDs,' but the search-oriented framing is clear enough that an agent can usually select it correctly.

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