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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantive behavior: only non-branded, question-like searches are returned, seeds are never copied into prompts, no volume/impression metrics exist, and 'unavailable no_search_data' signals no connected source. That last point is a genuinely useful error-state disclosure; only pagination/limits are missing.

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 purpose, then filtering, then the downstream handoff — a sensible order. It is dense but nearly every clause carries information; the 'never present a query as AI prompt volume' warning earns its place as a misuse guard.

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 no output schema, the description compensates by naming the returned fields, the filtering rule, the empty/error state, and the downstream consumer. Nothing essential to correct invocation appears to be missing.

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 project_id parameter, so the schema does the work and the baseline is 3. The description never explains project_id itself, and the mention of seed_source/seed_query_ids refers to generate_prompts' parameters rather than this tool's input, which could momentarily confuse an agent about this tool's signature.

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?

States a specific verb and resource ('List the searches a prompt generation run could ground its wording on') and names the two data sources (search_console, search_intelligence), which distinguishes it from siblings like read_search_dataset and read_query_evidence. It also enumerates the returned fields (id, text, topic), so an agent knows exactly what it gets.

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?

Clearly frames the tool as the grounding step that feeds generate_prompts, and explicitly tells the agent to pass results as seed_source and seed_query_ids. It does not compare itself against the other read_* search siblings, so the alternative-selection guidance is only partial.

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