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

Given readOnlyHint and openWorldHint already declare safety, the description adds meaningful behavioral context: residential proxy use, Bing's HTTP-only verticals, Copilot answers/citations, and Google's direct parsing of rich blocks. This gives an agent a realistic model of how results are obtained 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 compact and front-loaded with the core action. The Bing vertical enumeration in sentence 2 partly duplicates what the search_type parameter description already states, which prevents a perfect conciseness score, but the overall length is still reasonable and free of filler.

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?

For a 38-parameter tool with no output schema, the description plus the extremely detailed input schema provides enough orientation to select engines and verticals correctly. It does not describe the overall response envelope, but the rich schema carries most of the burden and mentions pagination metadata in parameter docs.

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?

The input schema provides 100% description coverage for all 38 parameters, including detailed semantics for num, page, search_type, and vertical-specific fields. The main description largely restates engine/vertical support already present in the search_type parameter description, adding no new parameter-level meaning, so the schema-covered baseline of 3 is appropriate.

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 clear verb and resource: 'Run structured Google, Bing or DuckDuckGo searches through a residential proxy.' It conveys a specific, multi-engine search capability, but it does not explicitly differentiate this tool from the sibling search_bulk or search_and_read tools, so it stops short of full sibling disambiguation.

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 main description provides context about engine-specific verticals and HTTP vs rendered behavior, implying when the tool is appropriate. Parameter descriptions add explicit routing guidance, e.g. num says 'Use page to address one specific page, or search_bulk for many queries.' No explicit when-not-to-use exclusions are given, so not a 5.

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