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

Beyond the readOnlyHint/openWorldHint annotations, it discloses substantial behavior: results cached in a local SQLite index, long pages truncated rather than refused, robots.txt honoured by default, and private/loopback addresses refused as a safety measure. These are exactly the operational traits an agent needs and are not derivable from the 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 front-loaded with the core behavior (fetch → clean Markdown) and then layers caching, truncation, and safety in tight successive sentences. It is dense but each sentence carries distinct information; only the long format enumeration is slightly list-like.

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 an 8-parameter tool with no output schema, the description covers return shape (Markdown main content, `next offset` for continuation), caching semantics, and safety constraints, which is everything needed to invoke it correctly. Nothing material is left unspecified.

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 all 8 parameters are already documented in the schema, and the description adds only the conceptual paging loop around `offset`/`max_chars` plus the supported file types. It reinforces but does not meaningfully extend the schema's parameter documentation, so the baseline 3 applies.

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 verb and resource ('Fetch one web page or document') and names the exact output ('clean Markdown' with navigation, adverts and cookie banners removed). It is clearly distinguishable from the plural sibling fetch_urls and from parse_document by emphasizing single-URL retrieval of the main content.

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 clear usage context: reading the same URL again is instant, the page becomes searchable offline with search_index, and the `next offset` is passed back to continue long documents. However, it never explicitly contrasts itself with fetch_urls for batch fetching or with parse_document, leaving the sibling routing 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 declare readOnlyHint and openWorldHint, so the safety profile is covered. The description still adds meaningful behavior beyond that: the 12-URL batch cap, per-URL failure isolation ('Failures are reported per URL instead of failing the whole call'), and the concurrent overlap that makes it fast. Remaining gaps are minor, such as the caching behavior behind the refresh param.

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 sentences, zero waste. The core capability and return shape are front-loaded, followed by the sibling comparison and then the failure-handling contract, in descending order of importance.

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 no output schema, the description carries the return-shape burden and does so adequately by describing per-URL Markdown sections and per-URL error reporting. Behavior is complete enough to invoke correctly, though ordering/pagination semantics and cache behavior are left to the schema.

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 the schema already documents urls, format, refresh, max_chars, and concurrency with enums and ranges. The description adds little parameter-level detail beyond echoing the 12-URL cap and Markdown default, so the baseline 3 for schema-driven parameters is appropriate.

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 gives a specific verb (Fetch), a resource (URLs), and a concrete scope: 'up to 12 URLs concurrently', returning 'each as Markdown under its own heading'. It also differentiates itself from the sibling fetch_url by naming it explicitly, so an agent can route between them without opening the schemas.

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 states a clear selection condition: 'Cheaper and faster than calling fetch_url repeatedly because the requests overlap', which tells the agent to prefer this tool over the single-URL sibling for batches. There is no explicit when-not guidance (e.g. use web_search when you have no URLs, or fetch_url when you need one page), so it falls short of the top score.

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=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: engines can be temporarily 'benched' after repeated blocks, which explains otherwise confusing absence from results. It does not cover rate limits or output shape, so it lands just short of a 5.

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, zero filler, with the content of the listing front-loaded and the actionable routing ('pick explicit engines for web_search') placed second. Every clause earns its place.

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 carries the return-value burden and does it by enumerating the four fields returned. Combined with the annotation-backed safety profile and the schema-documented format parameter, an agent has everything needed to call this correctly.

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 the single 'format' parameter is fully documented in the schema, so the description correctly stays out of it. Baseline 3 applies since the description adds no syntax or default-value detail beyond what the schema already provides.

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 ('Show every engine this server knows about') and enumerates exactly what the listing contains: indexed content, API-key requirement, tier, and current health. It also routes the agent toward web_search as the downstream consumer, so it is distinguishable from the other search/index siblings.

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?

Gives two concrete use cases: selecting explicit engines for web_search and diagnosing an empty result list. That is clear when-to-use guidance, but it stops short of an explicit exclusion or comparison against the other siblings (research, search_index, local_index).

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 flag destructiveHint=true and readOnlyHint=false, but they are tool-level and cannot say that the danger is confined to specific actions. The description adds per-action detail by naming `stats` as safe and `clear`/`prune` as permanently deleting data, which is genuinely useful disambiguation. It doesn't cover what `vacuum` does or what stats returns, so it stops short of a 5.

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 capability and immediately followed by the safety-relevant distinction. Every clause earns its place and nothing is padded.

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 an action-dispatch maintenance tool with 5 optional params and no output schema, the description covers purpose and the primary risk (permanent deletion). It could say more about what `stats` reports or how `vacuum` differs, but with 100% schema coverage and destructive annotations, the essentials are present.

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 the schema fully documents scope, action, format, max_pages, and max_age_days. The description only echoes the action names already enumerated in the schema, adding no syntax, defaults, or interaction detail beyond it, so the baseline 3 applies.

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 pairs concrete verbs (report, prune, clear, compact) with a specific resource: the local cache of fetched pages and recent engine responses. This is far more than a restatement of the name, though it never names or differentiates itself from siblings like search_index or list_engines.

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 line '`stats` is safe and cheap; `clear` and `prune` delete data permanently' hints at action selection, but there is no explicit 'use this when' guidance and no comparison to the sibling index/engine tools. The agent must infer that destructive maintenance is only warranted in specific situations.

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 cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower, and the description adds genuine context beyond them: local-only parsing with no upload or conversion service, plus per-format conversion behavior (spreadsheets to tables, presentations to one section per slide, PDF hyphenation/column repair). It does not discuss cost, size limits, or failure modes on remote fetches, but the added context is substantive.

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 sentences, front-loaded with what the tool does, then supported formats, then conversion specifics, then the privacy guarantee. Each sentence carries distinct information and nothing is repeated from the schema.

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 no output schema, the description usefully explains the return shape (text as Markdown, with format-specific structuring), and the schema handles offsets and mutual exclusivity. What is missing is any guidance on large documents or when a remote URL fetch would fail, but nothing an agent needs to invoke it correctly is absent.

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 all five parameters — including the url/path mutual exclusivity, sheet selection, format enum, and max_chars truncation with next offset — are already fully documented in the schema. The description adds only the format list and conversion outcomes, not parameter-level meaning, so the baseline 3 applies.

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 (read/parse) and resource (document from a local path or URL) and names the exact output (text as Markdown), plus an enumerated list of supported formats. It never names a sibling such as fetch_url or web_search, so the agent must infer the boundary between 'parse a document' and 'fetch a URL' on its own.

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 its niche — documents (PDF, DOCX, XLSX, etc.) rather than arbitrary web pages — but gives no explicit when-to-use or when-not-to-use statement and no alternative tool named. The presence of fetch_url/fetch_urls among siblings makes that omission a real gap.

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, but the description adds behavior annotations cannot: the server has no language model, so it does NOT paraphrase and the agent must write the synthesis itself. It also describes the actual return shape (verbatim passages, numbered citable sources), which is critical given there is no 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?

Front-loaded with the pipeline and clear value; every clause carries signal. Slightly long, and the depth elaboration partly overlaps the schema, but nothing is wasted 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?

With no output schema, the description carries the full burden of explaining return values and does so (Markdown brief, numbered sources, verbatim quotes, markdown vs json formats). It also flags the key limitation (no LLM synthesis server-side), so an agent knows exactly what it must do next.

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 earns above baseline by elaborating what depth actually does ('depth 2 = the query plus expansions derived from what the first page of results is actually about'), which the terse schema ('How hard to dig') does not convey.

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 compound action (search several engines, expand queries, fetch sources, extract answering passages) and names the exact output artifact (a Markdown brief with numbered citable sources and verbatim quotes). An agent can distinguish this from web_search or fetch_url without opening any 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?

Explicitly routes the agent: 'Use this instead of chaining web_search and several fetch_url calls whenever you need more than a snippet' — naming the alternatives and the condition ('more than a snippet') that selects this tool. It also gives depth-tier guidance so the agent knows which intensity to pick.

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=true and openWorldHint=false, so safety is covered; the description still adds real context beyond them — the FTS5 backend, CJK bigram matching, and the fact that it issues no network requests. It does not cover ranking, result ordering, or pagination behavior.

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 sentences, front-loaded with what the tool is, then usage, then return values and cost. Every sentence carries information; only the closing 'costs no network requests at all' slightly restates the earlier 'local/on this machine' framing.

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 read-only search tool with full schema coverage and annotations covering the safety profile, the description supplies the remaining essentials: what corpus is searched, when to use it, and what it returns (cached URLs, titles, highlighted snippets). No output schema is needed given that the return shape is described.

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 the schema already documents query, format, and max_results in detail, including the default and bounds. The description only reinforces the CJK bigram behavior, adding marginal meaning over the schema — baseline 3 applies.

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+resource+scope: full-text search over pages already fetched on this machine, backed by a local SQLite FTS5 index. It implicitly separates itself from the web_search/fetch_url family by stressing locality and zero network cost, but it never differentiates from the sibling 'local_index', which is a plausible source of confusion.

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?

Gives three concrete situations to reach for it: recalling something read earlier in the session, avoiding a re-fetch, and working offline. There is no explicit when-not or named alternative (e.g. 'for new content use web_search'), so routing is clear but not fully resolved.

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 only cover readOnly and openWorld, so the description carries the real behavioral burden and delivers: no API key by default, blocked/failing engines skipped and reported, and RRF fusion semantics explaining why results are stable. It stops short of describing latency, rate limits, or what the 'reported' failures look like, so a 5 is not warranted.

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?

Four sentences, each doing distinct work: capability, mechanism/justification, operational constraints, and sibling routing. Front-loaded with the core action and zero 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?

For an 11-parameter search tool with no output schema, the description covers capability, ranking behavior, failure handling, key requirements, and sibling routing, while the schema handles every parameter including output format. Nothing an agent needs to select or invoke it correctly 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 100%, so all 11 parameters are already documented, including site, engines, freshness, and max_results. The description adds no parameter-level detail beyond the schema (its site/fusion note duplicates the schema text), so the baseline 3 applies.

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 (search the web), names the multi-engine scope, and describes the output shape ('one de-duplicated, re-ranked result list'). This distinguishes it cleanly from fetch_url, research, and list_engines without opening any 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?

Explicitly routes between siblings: 'Prefer this over fetch_url when you do not yet know which page has the answer' and 'Use research() when you want the pages read for you as well.' Both the when and the when-not are stated with a selecting condition.

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