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

The description is transparent about the internal process: it runs SearXNG metasearch, opens pages with a real browser, distills relevant passages, and returns a merged digest. It also explains the refresh parameter's cache behavior, and the readOnlyHint annotation matches the read-only nature of the tool.

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 well-structured with a headline summary followed by a compact parameter list. It conveys substantial detail without unnecessary fluff, keeping every sentence purposeful.

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 fairly complex tool, the description covers the search engine, browser-based reading, per-source distillation, merged output, and cache refresh behavior. This is sufficient for an agent to understand what the tool does and what to expect as a result.

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?

Even though the schema has no per-parameter descriptions, the tool description compensates by explaining every parameter: query, max_sources, max_results, per_source_chars, time_range, category, language, and refresh. It includes value ranges and concrete examples, which is more informative than the raw 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 description opens with a crisp verb-resource statement: 'Search the web AND read the top sources in one shot.' It clearly differentiates this combined tool from the individual sibling tools by emphasizing the one-shot search-and-read workflow.

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 'Best first call for any research question,' giving a strong and direct recommendation for when to use the tool. This makes the usage context clear without needing to infer from sibling names.

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

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

The description discloses caching, refresh behavior, JS rendering, and boilerplate stripping, which go beyond the readOnly annotation. It does not mention network costs or rate limits, but the primary side effects are covered.

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 well-structured, with each feature stated in one clear sentence. No redundant information or 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?

Given the output schema and annotations, the description covers the main behavioral aspects an agent needs: content extraction, caching, and refresh. It could be slightly more explicit about edge cases, but overall it is complete enough for typical use.

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 schema has good parameter names and defaults, but the description adds only minimal explanation for query and refresh. It does not clarify the exact format of max_chars or how refresh interacts with cache, leaving some semantics implicit.

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 clearly states the tool reads one web page and returns main content as markdown. It distinguishes from siblings like web_search and deep_research, though read_urls is a close sibling that isn't explicitly contrasted.

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 explains general behavior (JS rendering, boilerplate stripping, caching) and the query parameter's effect, which implies when it might be used. However, it does not explicitly state when to prefer this tool over read_urls or web_search.

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

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

The annotation readOnlyHint is consistent with the read operation, and the description adds useful behavioral details: parallel fetching, JS rendering, boilerplate stripping, even budget splitting, duplicate merging, and skipped extras. Failure behavior is also disclosed as a failed page costing one line rather than a failed call.

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 efficient and well structured, with the high-level behavior, use case, and parameter details each getting their own section. There is minor repetition of ideas such as 'one call' and 'one round-trip', but nothing that significantly hurts clarity.

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?

The description is complete for an agent to select and invoke the tool correctly: it covers purpose, use case, parameter semantics, failure behavior, and important operational details. The presence of an output schema and readOnly/openWorld annotations reduces the need for additional output or side-effect explanation.

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?

Although the schema itself lacks property descriptions, the tool description fully compensates by explaining each parameter: urls constraints and deduplication, query as optional focus, total_chars as the combined budget, and refresh as cache bypass. This goes well beyond the bare schema and gives an agent everything needed to set parameters correctly.

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 precisely what the tool does: reads several known web pages in one call under a shared character budget. This clearly distinguishes it from sibling tools like read_url, web_search, and deep_research by emphasizing the batch and known-URL aspects.

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 recommends this tool over repeated read_url calls when the URLs are already known, and gives concrete reasons: one round-trip, one budget, and partial failure handling. This gives an agent clear, actionable selection criteria.

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

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

The description discloses that results are compact, that page content is not returned, and that empty/blocked results are retried automatically. The readOnlyHint annotation covers side effects; no contradictory claims are present.

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 well-organized with a short overview, behavior note, and per-parameter list. There is slight redundancy between 'compact ranked link list' and 'Returns title, URL and a short snippet per hit,' but overall it is efficient and scannable.

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 search tool, the description covers the main use case, output format, retry behavior, and key parameters. It does not explain the human-friendly list format in detail, but the schema and sibling-tool references provide enough context for correct invocation.

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 schema itself has no parameter descriptions, but the Args section adds concise semantics for every parameter, including examples for category, engines, language, and time_range. It also clarifies the as_json return shape with the JSON placeholder.

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 ('Search the web via SearXNG metasearch') and explicitly identifies the output shape ('compact ranked link list'). It also distinguishes itself from siblings by name and behavior, making selection clear.

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?

It explicitly tells the agent when to use this tool versus alternatives: 'To actually read pages, call read_url; to do both at once, call deep_research.' This removes ambiguity about whether the tool returns page content.

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