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

No annotations are present, so the description carries the full burden. It discloses per-URL error reporting, cost per call, caps on fetch_top and num_results, and parameter constraints. It does not mention rate limits or authentication, but for a read-only search+scrape tool these are minor gaps.

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 long but every section earns its place: purpose, error behavior, cost, and a structured parameter list. It is front-loaded with the core value proposition and avoids redundancy. The parameter list is necessary given the number of options.

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?

There is no output schema, so the description must convey return shape. It states the tool returns ranked search results with per-page markdown content and mentions error reporting. It includes caps and an example. Missing details like the exact JSON structure or whether content may be null for some results are not critical for a well-specified tool.

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 coverage is 0% because the schema only exposes a generic params object, so the description is the sole parameter documentation. It enumerates all parameters with explanations, caps, and an example, fully compensating for the missing schema details.

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 first line clearly states the tool combines web search and page reading into one call, with a specific purpose of answering with sources. It distinguishes itself from siblings by noting it returns both SERP and page content, eliminating a second scrape call.

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 implies when to use it (when you need search results plus page content) and contrasts with a two-call alternative ('without a second round of scrape calls'). It does not explicitly name sibling tools like serp or scrape, nor state when NOT to use it, but the context is clear enough for an agent to route appropriately.

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