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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not restate that. It does add useful context: it mirrors the Discover page's ranking and explicitly says it 'only discovers sources,' which clarifies scope. However, it does not disclose potential edge behaviors (e.g., exact match semantics, language handling) beyond what the schema states, so the incremental transparency is moderate.

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 a single focused paragraph that front-loads the core purpose, then quickly covers modes, sorting, and the follow_up pointer. Every sentence contributes value; there is no filler, but it could be tighter by merging the mode list into a more compact phrase. Still, it is well-organized and readable.

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 five parameters, an output schema, and annotations covering safety, the description covers the key usage scenarios, mode selection, and the boundary to follow_feeds. The output schema presumably defines the return shape, so no further explanation is needed there. It is complete enough for an agent to call correctly, though it does not discuss rate limits or default limit behavior, which the schema already hints at via limits property.

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 100%, so the schema documents every parameter. The description adds minor clarifications (e.g., 'omit query to browse suggested sources' and 'use sort=popular'), but these largely echo the schema text. Per the rubric, baseline 3 applies when the schema carries the load, and the description does not meaningfully exceed it.

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 opens with a specific verb and resource ('search feeds' via a discovery catalog) and immediately distinguishes itself from follow_feeds by stating it only discovers sources. It enumerates concrete use patterns (browse, search by topic, create Google News source, discover by URL), so an agent can tell it apart from siblings like search_web or search_article without inspecting schemas.

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 clearly explains when to use the tool (for discovery) and explicitly names follow_feeds as the alternative for following results. It also gives contextual cues like using sort=popular for popularity ordering, but it does not enumerate when NOT to use it against other search tools, so an agent might still need to infer that search_article is for articles.

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