Web Search Provider

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

Going beyond the annotations, the description discloses two meaningful behavioral traits: missing pinned keys and failed requests never trigger fallback, and provider snippets are untrusted data that do not establish factual support. The annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false) are consistent with 'perform a search request'; nothing here contradicts them. It could say more about the dry_run/authorize_submission gating that effectively controls whether a network submission occurs.

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?

Four short sentences, front-loaded with the action and followed by the two constraints that matter most (fallback policy, snippet trust). Phrasing is dense but every sentence carries content; no filler or restatement of the tool name.

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 an output schema present, return values need not be described, and the annotations cover safety hints. The description adequately covers the plan-vs-perform duality (matching dry_run's default) and the fallback semantics. The remaining gap is routing guidance relative to sibling search tools.

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% and the nested request object is documented, so the baseline is 3. The description does add one semantic fact the schema does not: the order in which providers are tried when backend='auto' (Serper, Tavily, Exa, Serply). Otherwise it adds no syntax, format, or bounds detail beyond the schema.

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 phrase 'Plan or perform one explicitly selected optional search request' gives a specific verb pair (plan/perform) plus the resource (a single search request with an explicitly selected provider), which is more precise than a generic 'search the web'. It does not, however, distinguish itself from near-siblings like web_search, research_web, or web_extract, so an agent cannot tell from this text alone why it would pick this tool over those.

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 never states when to use this tool versus the many search/extract siblings. The only quasi-usage content is the backend ordering for 'auto' mode and the no-fallback rule, which describe how a call behaves once chosen rather than when to choose it. No prerequisites beyond the implicit credential requirement are spelled out.

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