multi_search

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

With no annotations provided, the description must carry the behavioral burden, and it does: it reveals parallel execution, result merging, URL deduplication, and an agreement-based ranking rule. It doesn't mention potential rate limits, failure behavior, or exact output shape, but the core operational behavior is well disclosed.

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 two tightly written sentences with behavior and usage guidance front-loaded. Every clause contributes semantic value, and there is no redundant restating of the tool name or schema details.

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 moderately complex search tool with no output schema and no annotations, the description covers the key conceptual behavior, use case, and ranking logic. It does not explicitly describe what each result contains, but the mention of deduplication by URL and agreement ranking gives an agent enough to anticipate the output and decide whether to call it.

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 50%, and the description repeats the 'related queries' idea but adds little about the actual parameters. The language and time_range parameters are not described in the schema or the description, though their names are reasonably self-explanatory. The count_per_query default is already in the schema, so the description adds minimal parameter-level value.

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 states a specific action ('Run several related queries in parallel'), the target resource, and the distinctive behavior of merging, deduplicating by URL, and ranking by sub-query agreement. This clearly differentiates the tool from a ordinary web search and makes its purpose obvious without needing to inspect the schema.

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 explicitly says to use this tool for exploratory research on a topic, 'search this from a few angles', and contrasts it with a single precise lookup. It gives clear usage context and an exclusion, but it does not name the exact alternative tool (e.g., web_search), making this slightly incomplete.

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