deep_search

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

With no annotations, the description carries the full behavioral burden, and it does disclose meaningful mechanics: Google querying, full-page content extraction via the Readability algorithm, consolidation of results, and retry logic. What is missing is the operational envelope for a network-bound search tool - rate limits, latency expectations, failure/empty-result behavior, and whether content is truncated or cached.

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?

Three sentences, front-loaded with the core action, then supported capabilities, then a reliability note. Nothing is redundant, though the trailing 'Includes retry logic for reliability' is the weakest sentence and could be folded into the behavioral detail rather than standing alone.

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 annotations and no output schema, the description must carry the load, and it partially does by describing the consolidated-content return. However, for a six-parameter search tool with a sibling that overlaps, it lacks any statement of how results are shaped (per-result structure, truncation at max_content_per_page) and gives no basis for preferring it over deep_search_news.

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 every parameter including query, num_results, search_type, domain filters, and max_content_per_page is already fully documented in the schema. The description adds only the high-level mention of web/news/image search types, which does not extend beyond the enum already documented. Baseline 3 applies.

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 names a specific verb and resource (web search) and details the mechanism: querying Google, fetching full content from top results via Readability, and returning consolidated content. It also enumerates the supported search types. However, it never distinguishes itself from the sibling deep_search_news, even though it claims to handle news search itself, which muddies selection.

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?

There is no explicit guidance on when to choose this tool versus the sibling deep_search_news, despite the obvious overlap since this tool also supports a 'news' search type. The only hint is the enumeration of search types, which implies context but stops short of routing the agent. No exclusions or prerequisites are given.

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