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?

Annotations declare readOnlyHint and openWorldHint, so the description builds on that with valuable behavioral details: caching behavior, version pinning fallback ('wrong/missing tag on GitHub also falls back to latest with a note'), subpages navigation logic, and the fact that output is distilled passages rather than full docs. No contradictions with 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 longer than average but well-structured: a clear opening sentence, a Context7-style comparison, a bullet list of parameters, and notes on version behavior. Every sentence contributes meaning; it is detailed but not wasteful. Slight redundancy ('local and unlimited' vs caching) but overall efficient.

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 tool's complexity (6 params, output schema present), the description is remarkably complete. It covers parameter semantics, edge cases (version fallback), caching, distillation, and output constraints. An agent has all necessary information to call the tool correctly, including what to expect in the answer.

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%, so the description carries the full burden. It explains every parameter: library with examples, query for distillation, max_chars as character budget, refresh for cache bypass, subpages with '0 disables', and version with tag examples and fallback behavior. This fully compensates for the lack of schema descriptions.

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 specific verb and resource: 'Fetch up-to-date official documentation for a library and distill it under your question.' It clearly identifies the tool's unique function (distillation) and distinguishes it from general web search or URL reading by its focus on library docs and local caching.

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 provides strong usage context: it explains the built-in index, caching benefits ('instant, offline and free'), and the distillation process. It mentions 'Context7-style' as a comparison but does not explicitly name sibling tools or state when NOT to use them. However, the context is clear enough for an agent to infer appropriate usage for library documentation queries.

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?

With annotations already declaring readOnlyHint and openWorldHint, the description adds substantial behavioral detail: headless browser handling, boilerplate stripping, query filtering, caching with no network on re-reads, and exact find semantics with counters and context. This goes well beyond the annotations and fully discloses side effects like cache usage.

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-organized with a clear intro, a behavior paragraph, and an args list. It slightly repeats 'query' behavior between the intro and the args list, but every sentence earns its place. The front-loaded purpose and structured parameter explanations make it easy to scan.

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 tool with 5 parameters, no schema descriptions, and an output schema available, the description fully equips an agent: it covers parameter semantics, caching, network behavior, and the specific semantics of find. The presence of an output schema means return value details don't need duplication. Nothing necessary for correct invocation is missing.

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 0%, so the description carries the full burden. It explains every parameter: url format, query filtering, max_chars budget with range, refresh ignoring cache, and find's case-insensitive exact match with requirements (must have been read before). This adds rich meaning the schema completely lacks.

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 specific verb+resource: 'Read one web page; return its main content as clean, budgeted markdown.' This clearly differentiates it from sibling tools like read_urls (plural) and web_search. The additional behaviors (JS rendering, boilerplate stripping) make the purpose unmistakable.

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 gives context for when to use parameters (query for relevance, refresh to bypass cache, find for cached text) but never explicitly states when to prefer this tool over siblings like read_urls or web_search. Storage and caching behavior indirectly imply single-page reads, but no alternatives or exclusions are named.

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?

Beyond the readOnlyHint and openWorldHint annotations, the description fully discloses behavior: no LLM involvement, extraction from user-provided or search-found sources, lexical scoring with negation handling, possible verdict categories, use of cache, and the refresh flag to bypass caching. This is rich and accurate context.

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 organized with a clear summary first, then behavior, then a compact Args list. Every sentence adds value, and no information is repeated from the schema. It is detailed without being bloated.

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 tool's moderate complexityched, the description is complete: it explains the deterministic method, verdict types, source selection behavior, all parameters, and the appropriate use case. The output schema exists, so return-value details do not need to be repeated in the description.

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 0%, but the description compensates fully by documenting all four parameters in the Args block. It adds constraints not present in the schema (e.g., urls 1-10, max_sources 1-10, refresh meaning) and clarifies supported languages for claim.

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 specific verb and resource: 'Deterministically verify a claim against web sources; return a verdict with quoted passages.' It also distinguishes itself from siblings by emphasizing reproducibility, lexical scoring, and verdicts rather than narrative or open-ended research.

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 states the intended use case: 'Best for checking a fact, assertion or rumour when you need a reproducible verdict with citations, not a narrative.' It also explains when to supply URLs versus rely on web search. It does not name sibling tools explicitly, but the 'not a narrative' exclusion gives clear decision context.

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.