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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add context — and it does: "Honors per-domain auth and proxies" discloses credentialed fetching behavior that no annotation conveys. It also notes the implicit tables:true default when no selectors are supplied, though it says nothing about failure behavior on non-200 pages or timeouts beyond the parameter itself.

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?

Front-loaded with what it produces, then how, then when — a logical order with no filler sentences. It is dense in the selector sentence but every clause carries information; only mild tightening would be possible.

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?

With an output schema present, return values need no explanation, and the description covers mode selection, selector shape, table extraction, and credentialed/proxied fetching. For a 4-parameter tool with a nested selector object, that is close to complete; only error/empty-result behavior is unaddressed.

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 100%, so the baseline is 3; the description earns above that by explaining the semantics of the selector map in prose (named fields, text vs attribute, first match vs all) and clarifying the conditional default "tables:true when no selectors are given" — a cross-parameter interaction the schema only states one-sidedly.

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?

"Extract specific values from a web page as JSON instead of markdown prose" names a concrete verb and resource and immediately contrasts the output shape with the whole-page/markdown siblings (fetch, research). An agent can distinguish extract from fetch without opening either 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?

"Use this when you need particular data (prices, lists, specs, tabular data) rather than the whole page" gives a clear selection rule with concrete examples. It stops short of naming the alternative tool (fetch) explicitly or stating when not to use it, so it is strong but not fully routing-grade.

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 annotations (readOnly, idempotent, non-destructive, open-world), the description discloses the real behavioral story: a tiered retrieval ladder (shared cache, native Markdown/direct HTML, hosted rendering, labeled archive fallbacks) and the fact that authenticated requests bypass fallback sources and caches. That is valuable, non-obvious context an agent cannot get from annotations or schema; it only lacks detail on failure signaling.

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?

Dense but front-loaded: capability and return shape first, then handler coverage, then the fallback ladder, then operational knobs. Nearly every sentence carries information, though the tier/fallback sentence is compressed enough to require a second read.

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?

With 8 parameters, full schema coverage, and an output schema that already documents return values, the description covers everything else an agent needs: what it retrieves, in what form, what fallbacks occur, how authentication changes behavior, and how to page through large results. Nothing material is missing 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?

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: it explains the tier ladder that maxTier caps and describes the intended use of startIndex/maxLength for paginating long content, plus the interaction between noCache and archive fallbacks. This makes the truncation and caching controls understandable as a system rather than as isolated fields.

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 sentence gives a specific verb (fetch), resource (public or authenticated URL) and concrete output shape (readable Markdown plus source, retrieval time, hash, completeness), and names the special-cased hosts (GitHub, Wikipedia, YouTube, PDFs, arXiv, tweets). It never names or distinguishes itself from the siblings extract, fetch_batch, research or search, so an agent gets no explicit routing signal between them.

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?

Operational guidance is present: paginate long pages with startIndex and maxLength, noCache forces retrieval and disables archives unless allowed, and authenticated requests are restricted to direct sources. However there is no when-to-use-this-vs-alternative guidance, so the agent must infer that batch fetching belongs to fetch_batch and structured extraction to extract.

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 already declare readOnly, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: parallel execution, markdown normalization, reuse of the same handler/fallback chain, and a reduced per-URL output budget. It does not say how per-URL failures or partial results are surfaced.

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?

Two sentences, front-loaded with the core behavior and batching cap, followed by the differentiator and the usage cue. No padding or redundant restatement of the name or title.

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?

With annotations, a complete input schema and an output schema, the description covers purpose, scale and routing well. The one meaningful gap for a batch tool is partial-failure semantics, which an agent may need before committing to ten URLs.

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 100%, so every parameter including maxTier, noCache, maxLength and timeoutMs is already documented, which sets the baseline at 3. The description only adds that the length budget is smaller than the single fetch tool's, without giving the concrete value or explaining the tier/archive interplay.

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?

States a specific verb and resource ('Fetch up to 10 URLs in parallel') plus the return format ('clean markdown'), and implicitly differentiates from the single-URL fetch sibling by calling out the smaller per-URL length budget.

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?

'Use after a search to pull several sources in one call' gives a clear triggering context, and the reference to 'the fetch tool' with a smaller per-URL length budget hints at when to prefer the single-URL sibling. It stops short of an explicit when-not-to-use rule or a blanket statement of alternatives.

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 already declare readOnlyHint, openWorldHint and non-destructiveness, so the safety bar is lower, and the description usefully adds that results come back as full markdown content per result. It does not mention pagination, truncation at maxLength, or that the DuckDuckGo fallback silently ignores freshness, but those are largely covered by schema descriptions and the output schema.

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?

Three short sentences with zero redundancy: the action, the return shape, and the routing rule are each delivered once and front-loaded in that order.

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?

With an output schema present and full schema coverage, the description need not explain returns or parameters, and it correctly stays high level for a seven-parameter composite tool. A small gap remains in not flagging the composite's heavier cost relative to a bare search, which would help an agent choose between this and its siblings.

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 100%, so every one of the seven parameters is already documented in the schema, including count, site, freshness and passagesOnly. The description adds only loose framing ('top results', 'full content'), which touches on count and passagesOnly but supplies no new syntax or defaults, making the baseline 3 correct.

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 concrete verb pair and resource ('Search the web and fetch the content of the top results') and explicitly frames itself as a single-call composite, which separates it from the sibling 'search' and 'fetch' that it replaces.

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 gives an explicit when-to-use rule: 'Use this instead of separate search + fetch calls when researching a topic.' That is clear routing guidance, but it does not address when to prefer the sibling 'fetch_batch' (multi-URL retrieval) or 'extract', leaving those distinctions to inference.

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 already cover the safety profile (readOnly, openWorld, non-destructive, non-idempotent), so the description's added value is the provider chain — Brave first, then SearXNG, then DuckDuckGo — which tells the agent results and capabilities can vary by deployment. It stops short of saying results are non-deterministic across retries, which matters given idempotentHint=false.

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?

Three short sentences, purpose front-loaded, then environment-dependent behavior, then capabilities. No filler, though the feature list marginally repeats the schema's parameter names rather than adding information.

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?

With an output schema present, return-shape explanation is unnecessary, and annotations plus schema cover safety and parameter constraints. The description completes the picture with the backend fallback chain, which is the one behavior an agent could not learn from structured fields.

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 100% and every parameter carries its own description with ranges, defaults, and the DuckDuckGo caveats, so the schema does the heavy lifting. The description names site, freshness, and page but adds no semantics beyond what the schema already states, and ignores count and timeoutMs.

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?

"Search the web and return results" gives a specific verb and resource that an agent can act on immediately, and the provider-fallback sentence adds useful scope. It does not distinguish itself from siblings like fetch, extract, or research, so an agent must still infer that this is for discovery rather than retrieving known URLs.

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?

Usage is only implied by the verb "search"; there is no explicit statement of when to prefer this over fetch, extract, fetch_batch, or research. The fallback chain hints at reliability trade-offs, but the agent gets no routing guidance.

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