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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial non-structured behavior: cache hits return instantly without a browser, inter-navigation rate limiting guards against CAPTCHA, batches of ≥8 URLs run in a thread pool with per-thread browsers, and max_chars truncates only the response, not the crawl. This is richer than typical annotation coverage.

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: purpose, then cache/rate-limit/parallel behavior, then an example, then when/not-when. The dated benchmark timings (36.4s/30.3s/45.9s) are somewhat verbose, but they justify the tuning advice and are not pure 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?

An output schema exists, so return values need not be explained, yet it still notes the '--- URL: ...' text separators. Given four parameters, no schema descriptions, and a parallel/cached execution model, the description supplies everything an agent needs to call it 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 0%, so the description must carry all four parameters — and it does: urls (scale guidance), max_chars (concrete ranges 4000-100000 with measured tradeoffs), article_only (Trafilatura extraction excluding menus/banners), and max_parallel (explicit cap on auto-detected workers). A worked example demonstrates combined usage.

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 ('Открывает НЕСКОЛЬКО URL в одном браузере') plus the scale it targets (30-50 sources, one call instead of cold starts). An agent can immediately distinguish it from fetch_page and the other fetch-adjacent 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?

Contains explicit 'КОГДА' and 'НЕ КОГДА' sections: use for 10-50 URLs after research/crawl/map_site; use fetch_page for 1-2 pages; gather URLs first via research, sitemap, map_site. Alternatives and exclusion conditions are named outright.

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 (read-only, open-world, idempotent), and the description adds substantial behavior beyond them: per-link timeout semantics, bounded worker pool via CAMOUFOX_LINK_WORKERS (default 8, cap 16), forced sequential execution under live-browser mode, and the 900s call budget with client-timeout advice.

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 WHEN/WHAT/NOT structure makes it scannable, and the concurrency caveat plus timeout budget genuinely earn their space. It is dense with operational detail, but none of it is padding given the described pitfalls.

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 format need not be restated, and the description covers the runtime constraints, failure mode, and budget that an agent needs to invoke this correctly. Nothing material 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 coverage is 0%, so the description must carry the load, and it explains the two non-obvious params: timeout is per-link (15s), not total, and internal_only controls whether external links are checked. max_links is only implied via the 50-link/min figure, so it is slightly short of complete.

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: find broken links on a page and report HTTP statuses as «[404] URL». That clearly distinguishes it from extract_links (which only gathers URLs) without needing to name the sibling explicitly.

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?

Explicit WHEN (before publishing or after a redesign) and explicit NOT (don't expect parallelism when a live browser is up; external links require internal_only=False). The conditions that select behavior are spelled out, including the observed failure mode.

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/openWorld, and the description adds operational traits they cannot express: caching makes repeat crawls cheap, a crawl takes tens of transitions, and the MCP client timeout should be ≥900s. That is exactly the kind of cost/latency disclosure an agent needs before committing.

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 КОГДА/ЧТО/НЕ structure front-loads purpose, then output shape and cost, then exclusions. Every line is load-bearing with no filler, despite covering a fairly complex tool.

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?

Output-schema existence relieves it of return-value detail, and it adds timeout/caching context and alternatives. The remaining gap is the unexplained max_chars, article_only and pattern semantics, which leaves a 6-param tool partially under-specified.

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 must carry parameter meaning, and it only covers url (implied), max_depth and max_pages ('depth ≤ max_depth, всего ≤ max_pages') plus a passing nod to pattern. max_chars and article_only are never explained, leaving half the parameters undocumented.

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 'ЧТО' line names the resource (страницы сайта) and the mechanism (BFS по внутренним ссылкам), explicitly scoping it to a whole site rather than one page. An agent can distinguish it from fetch_page and map_site from the text alone.

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 'КОГДА' and 'НЕ' sections give explicit when-to-use and when-not-to-use with named alternatives: URL-only needs → map_site/sitemap, huge site → sitemap + pattern then crawl a section, single page → fetch_page. This is textbook routing guidance.

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=false and destructiveHint=true, so the agent knows this is a write operation. The description usefully adds the default output location (~/.cache/camoufox-research/exports/) when no path is given. However, it does not explain the destructive semantics the annotation implies — e.g., whether it overwrites an existing file at a user-supplied path.

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 labeled lines (WHEN/WHAT/NOT) with zero filler and the usage condition front-loaded. 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?

With an output schema present, return values need not be described, and the description covers usage, formats, and default destination adequately for a simple 3-param tool. The remaining gap is destructive/overwrite behavior, which the annotation hints at but the description never addresses.

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 must carry the load. It explains the format choices (json/csv/md) and the path behavior (own path or auto cache location), which compensates for two of three params. It does not clarify the required `data` parameter, and omits the 'markdown' enum alias present in the 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 uses a clear verb+resource framing (export a result to a file) and names the concrete output formats (CSV for tables, JSON for automation, MD for report). It distinguishes this tool from the conversation/synthesis path and from the many fetch/research siblings by scoping it to disk output.

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 explicit WHEN/WHAT/NOT structure states when to use it (result needed as a file on disk), what it produces, and when NOT to use it (result goes into conversation and synthesis → pass text as-is). This is exactly the routing guidance an agent needs.

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 readOnly/openWorld/idempotent/non-destructive, but the description adds real behavioral context beyond them: llm=True requires an LLM backend (DeepSeek/Ollama) and otherwise returns an honest 'unavailable' answer, and schema is accepted as a JSON string for compatibility. Minor gaps remain (rate limits, whether extraction is bounded per page).

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 labeled sections (КОГДА / ЧТО / НЕ) pack the routing decision, format spec, and exclusions into a few dense lines with no filler. Every clause carries information an agent needs.

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 not be described; the description instead covers selection criteria, parameter encoding, backend dependency, and sibling alternatives, which is complete for a 3-param extraction tool. The reference to 'snapshot' (absent from the sibling list) is the only nit.

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 must carry the load, and it does: it documents the schema parameter's css:/XPath prefix syntax, the {selector, attr: text|href|src} object form, and the llm hint form, plus llm=True's backend dependency. Only url is left unexplained, which is self-evident.

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 'ЧТО' block states a precise verb+resource (extract named page fields) and immediately distinguishes the two modes (selector-based vs llm=True). It is trivially separable from siblings like fetch_page or table_extract.

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 'КОГДА' and 'НЕ' blocks give explicit when-to-use, when-not, and name the concrete alternatives (fetch_page / batch_fetch for raw text, table_extract for tables, snapshot when the selector is unknown). Routing is unambiguous.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only the substring-filtering behavior; it says nothing about fetching live pages, rate limits, or failure modes on unreachable URLs.

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?

A single compact sentence with the resource named first and the filter qualifier second; nothing is wasted, though brevity here borders on under-specification rather than efficiency.

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?

An output schema exists, so return values need not be explained, and annotations cover the read-only/idempotent profile. For a simple three-parameter tool this is minimally viable, but the undocumented url and max_links parameters and absent sibling routing leave real gaps.

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 must carry parameter meaning, and it explains only one of three parameters (pattern as a substring filter). The required url and the max_links cap (default 20) are left entirely undocumented in both the schema and the description.

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: it collects the links of a page, with an optional substring filter. That is clear enough for an agent to know what it returns, though it never distinguishes itself from near-siblings like check_links, extract, or crawl.

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?

There is no when-to-use guidance and no mention of the alternatives in the sibling set (e.g. check_links for validation, crawl for whole-site traversal). The parenthetical filter hint implies one capability but does not tell the agent when this tool is the right choice.

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 establish read-only, idempotent, non-destructive, open-world behavior, but the description adds material context beyond them: a ~24h cache, how delta avoids re-emitting unchanged content, and that max_chars truncates only the response while the full page (up to 100k) is cached. That directly affects token and retry decisions.

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 core purpose, then semantics, then the when/when-not routing. Dense but nearly every clause earns its place; the parenthetical benchmark measurement (21.09 timings, 26%/87% figures) is more illustrative detail than an agent strictly needs.

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?

An output schema exists so return structure needn't be documented, yet the description still explains the one non-obvious return case (delta marker). With caching, truncation, extraction fallback and sibling routing all covered, 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 coverage is 0%, so the description carries the full burden and does: it defines delta (marker instead of text on unchanged content), article_only (Trafilatura article extraction with full-body fallback), and max_chars (response-only truncation with cache reuse). Only url is left to self-evidence, which is reasonable.

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 (read one page as clean text, JS/SPA included) and immediately differentiates itself from siblings: batch_fetch for 10+ pages, extract for schema fields, session_start for interaction. No sibling overlap is left ambiguous.

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?

Explicit КОГДА / НЕ КОГДА block with named alternatives for each exclusion case (batch_fetch, extract, delta=True, session_start). This is the strongest form of routing guidance.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuine context beyond them: it does not read page content, it stays on the same domain, and it caps results at max_links, plus a relative cost hint versus sitemap ('дешевле'). No return format is described, but that is a minor gap given the annotation coverage.

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 labelled lines, front-loaded with the goal, then the mechanism, then the exclusions. No filler sentences; 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?

An output schema exists, so return values need not be explained. For a read-only mapping tool with rich annotations, the WHEN/WHAT/NOT triad plus the sibling routing makes the definition complete 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 description coverage is 0%, so the description must carry the parameter burden. It does explain pattern ('фильтр по URL') and max_links ('до max_links'), but url is only implied and there is no syntax guidance for pattern (regex vs substring) or what the cap default means. Partial compensation for a 0% coverage 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 ЧТО line gives a concrete verb+resource: 'ссылки того же домена со стартовой страницы (до max_links)', and the КОГДА line frames the goal ('понять структуру сайта... без чтения содержимого'). It is immediately distinguishable from crawl, sitemap and fetch_page.

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?

Explicit WHEN/WHAT/NOT structure names the alternatives by tool name and the condition that selects each: 'нужны тексты → crawl; есть sitemap.xml → sitemap (полнее и дешевле); одна страница → fetch_page.' Nothing is left 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 readOnly, idempotent, openWorld, non-destructive. The description adds the critical behavioral constraint not in annotations: it diffs against a cached prior read and is meaningless without one. It doesn't discuss caching expiry or what happens when no cache exists, but the core dependency is disclosed.

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 WHEN/WHAT/NOT structure front-loads the deciding condition and packs scope, mechanism, and exclusions into three tight lines with no 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 a monitoring/diff tool the description covers the deciding context, the cache prerequisite, and the fallback, and an output schema exists so return values need no explanation. The only real gap is the undocumented max_chars parameter.

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% and the description mentions neither parameter. The required url is obvious from context, but max_chars (default 6000) is left entirely undefined in both schema and description, so an agent gets no guidance on the output-size knob.

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 ('дифф свежего чтения с прошлым из кэша') and explicitly frames what it produces ('что поменялось'). It cleanly distinguishes itself from fetch_page, so an agent can route 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?

The description is organized as explicit WHEN / WHAT / NOT sections. It names the prerequisite (page already read), the exclusion (first read → fetch_page), and the alternative for full text (fetch_page). This is textbook routing guidance.

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/openWorld/idempotent/no-destructive, so safety is covered. The description adds real behavioral context beyond them: no API keys needed, results include year/authors/citation counts, and a one-day cache that affects freshness of repeated queries.

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 core action, then defaults, then an example — a sensible order. Some parenthetical industry commentary ('паттерн индустрии: vertical index…') is filler that could be trimmed without losing 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?

An output schema exists, so return values need not be spelled out, and the description still summarizes the shape (year/authors/citations). Combined with the documented sources semantics and cache behavior, an agent has enough to call this correctly; only max_results remains 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 description coverage is 0%, so the description carries the load. It documents sources effectively (allowed values arxiv/semantic/crossref/wiki, default behavior, and an example), but max_results and the query field are left entirely to the schema, so it doesn't fully compensate for the gap.

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 ('Поиск научных статей') and enumerates the two backends (arXiv + Semantic Scholar). It explicitly contrasts its scope with general search ('которых общий поиск почти не видит'), letting an agent distinguish it from the web_search sibling 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?

Gives clear operating context: free APIs without keys, 24h cache, and how to select indexes via sources with defaults (empty = arxiv+semantic) plus a concrete example call. It does not name web_search explicitly as the alternative to avoid, so routing is implied rather than stated.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds non-obvious context the annotations cannot: that this is an application-level health probe rather than the removed protocol `ping`, and that the name is a frozen public contract. That is genuine value beyond the 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?

The core behavior ('returns pong') is front-loaded in the first clause. The remaining notes about the spec version and the fixed name are slightly meta and consume space an agent doesn't strictly need, but they serve a real purpose in preventing misuse of the name, so they largely earn their 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?

For a trivial zero-parameter health check with a full output schema and rich annotations, the description supplies everything relevant: behavior, semantics of the name, and safety is covered structurally. Only the 'when to call me' trigger is left implicit, which is the one minor gap.

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 tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify, and it introduces no misleading parameter hints.

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 behavior — a health check that returns 'pong' — and explicitly distinguishes itself from the protocol-level `ping`, which prevents an agent from mistaking it for a network diagnostic. What the tool does is unambiguous. It doesn't need to differentiate from siblings since none of the listed tools (crawl, fetch_page, web_search) are comparable.

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 identifies itself as an application health tool, which implies the use case (connectivity/liveness check), but it never states when an agent should call it — e.g. before a batch of operations, or to verify server availability. No alternatives or exclusions are named because none exist among the siblings.

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 readOnly/idempotent annotations, it discloses real operational constraints: local paths are restricted to the server download directory populated by session_download, and arbitrary paths require the CAMOUFOX_ALLOW_ANY_PATH=1 gate. It also notes that old .doc/.xls formats fail and output is truncated at max_chars. This is substantial context, though permission/auth details for remote URLs are not 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 КОГДА/ЧТО/НЕ front-loading is efficient and scannable, and every block earns its place. The parenthetical library names and format-conversion aside add density that a reader must parse, but nothing is wasted.

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?

An output schema exists, so return-value description is unnecessary, and the description covers the remaining gaps: input constraints, path restrictions, format limitations, and the cheaper alternative for HTML. An agent has everything needed to invoke it 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 coverage is 0%, so the description must carry the load, and it does: 'source' is defined as a URL or local path with the directory restriction, and max_chars is framed as the truncation ceiling (default 6000 implied by schema). It adds meaning beyond the bare schema, though it does not describe accepted URL schemes or path syntax in detail.

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 'ЧТО' (WHAT) block states a specific verb and resource: extracts the text of a document (PDF/DOCX/XLSX), naming the underlying libraries. It explicitly distinguishes itself from the sibling fetch_page for HTML pages, so an agent can separate it from the other extraction tools.

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 КОГДА/НЕ structure gives explicit when-to-use ('нужен документ... отчёт, прайс, спецификация') and when-not ('HTML-страница → fetch_page (дешевле)'), naming the alternative and the reason it is preferred. It also routes legacy .doc/.xls users to a conversion step first.

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, openWorld, and non-destructive behavior. The description adds major behavioral context beyond annotations: daily caching, long runtime up to ~15 minutes with a 900s internal timeout, a warning not to poll, API key requirements for llm_planner, and token-cost implications for fetch_all. No contradiction with the read-only/idempotent 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 long, but the length is largely justified by the 16-parameter surface and the need to document behavior in the absence of schema descriptions. It is front-loaded with when/what, but the benchmark measurement and some tightly packed parameter shorthand make it slightly heavier than necessary.

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 complexity, zero schema description coverage, and the fact that an output schema exists, the description is complete. It covers selection guidance, defaults, advanced parameters, return shape for as_json, timeout expectations, and key dependencies, so an agent has what it needs to call the tool 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 0%, so the description must carry the parameter semantics, and it does so almost completely. It explains queries, fetch_top, max_chars, max_parallel, target_domains, domains_limit, expand, terms_wave, quality_first, fetch_all, as_json, academic, llm_planner, and mode, with defaults and effects. Only article_only is left unmentioned, which is a minor omission in an otherwise thorough namespace.

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: deep research, retrieving 10+ sources on a topic in one call, with no background wait. It explicitly distinguishes from the sibling web_search for single facts, news, or exact URLs, so an agent can select it without opening the 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?

The description gives explicit when-to-use ('нужно СЕЙЧАС 10+ источников...') and when-not-to-use ('Один факт, новость или точный URL — это web_search') guidance. It also provides default parameter advice and an advanced example, leaving no routing ambiguity.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond them — that the feed returns dates in one call and lists returned fields (title, link, date) — but does not discuss rate limits or error 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 tight labeled blocks (WHEN/WHAT/NOT) with zero filler, front-loading the trigger before the exclusions. Every line earns its place and is 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?

An output schema exists, so return-value explanation is not required. Combined with rich when/when-not guidance and sibling routing, the description gives an agent everything needed to invoke this two-parameter read tool 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 0% for both parameters. The description partially compensates by clarifying 'до limit' (up to limit results), giving the limit parameter meaning, but 'url' is left entirely to the schema and no format/behavior detail is added. With only partial compensation for the coverage gap, this sits at the baseline.

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 ЧТО block states a specific verb and resource: fetch RSS/Atom posts with title, link, and date fields. It is clearly distinguishable from siblings like fetch_page (HTML pages) and crawl/map_site (whole-feed monitoring), so an agent can pick it without opening the 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?

The КОГДА block gives explicit positive triggers (news, blog, changelog, releases) and the НЕ block names two concrete alternatives with the conditions that select them: fetch_page for ordinary HTML, crawl/map_site for full-feed monitoring. This is textbook when/when-not/alternatives guidance.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by disclosing supported sitemap sources and the max_links cap, though it does not mention auth requirements or rate limits.

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 KOGDA/CHTO/NE structure is compact and front-loaded. Each line earns its place, with no redundant explanation.

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 rich annotations and output schema mean return format and safety notes are covered. The description handles usage and alternatives well, but the undocumented url parameter keeps it from being fully complete.

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 must compensate. It clarifies that max_links caps the number of URLs, but the required url parameter is never explicitly defined or given a format, leaving a significant semantic gap.

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 WHAT clause states a specific resource and scope: URLs from sitemap.xml, .xml.gz, and nested sitemapindex, up to max_links. It explicitly distinguishes the tool from siblings by naming map_site and crawl for different needs.

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 KOGDA and NE sections give explicit when-to-use conditions and alternatives: use for a full page list, crawl feed, or domain check; if no sitemap use map_site; for texts use crawl. Nothing is left 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 cover only the safety profile (readOnly/idempotent/non-destructive). The description adds genuinely new behavioral context: secrets are masked in returned call data, and availability rules (ALWAYS_ON in caps profiles, overridable by CAMOUFOX_TOOLS_ONLY / CAMOUFOX_TOOL_HIDE). This is exactly the kind of trait annotations cannot express.

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 WHEN/WHAT/NOT labels and no filler. The profile-visibility clause is somewhat dense but conveys a real constraint rather than padding.

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?

An output schema exists, so return values needn't be spelled out, and the description covers purpose, alternatives, masking, and availability. The only gap is the undocumented `limit` parameter, which leaves the agent guessing at how much data is returned.

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% and the single `limit` parameter (default 20) is completely unexplained in the description. Since coverage is below 50%, the description is expected to compensate, but it says nothing about what limit controls (recent calls shown?) or its bounds.

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 resource (per-tool call statistics) with concrete contents: call counter, average time, errors, and recent calls. The НЕ block explicitly distinguishes it from two named alternatives (tool_usage.json and ping), so an agent can identify it without opening the 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?

Uses an explicit WHEN/WHAT/NOT structure. 'КОГДА' names the use case (auditing which tools work and what fails, client debugging), and 'НЕ' names the alternatives for the adjacent questions (usage metrics via tool_usage.json, server health via ping). Nothing is left 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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by specifying that output is CSV text and that extraction is capped by max_tables, though it does not discuss pagination or error 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?

The description is tightly structured into WHEN, WHAT, and NOT sections, is front-loaded with the triggering condition, and contains no wasted sentences.

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 simple extraction task, rich annotations, and an output schema, the description covers routing and basic behavior well. Parameter titles and defaults in the schema fill most remaining gaps, though explicit url semantics are still absent from 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%, so the description must compensate. It clarifies that selector is a CSS selector and that max_tables limits the number of extracted tables, but it does not explicitly explain the required url parameter or the default values already present in the 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 states a specific verb and resource: extract table content as CSV text using a CSS selector. It also distinguishes the tool from siblings by naming cases where extract, fetch_page, or snapshot are preferable instead.

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 WHEN/WHAT/NOT structure explicitly states when to use this tool, when not to use it, and which alternative tool to use in each excluded case. This leaves little ambiguity for an agent choosing among extract, fetch_page, and table_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 cover read-only/idempotent/non-destructive/open-world, and the description adds real context beyond them: anti-detect browser backend, 24h cache, engines defaulting to the CAMOUFOX_SEARCH_ENGINES chain, HTTP fallback being faster, and browser transport required for JS/consent engines.

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 Когда/Что/Не когда and no filler sentences, but the 'Что' block is a dense run-on with nested parentheticals and example values that takes effort to parse.

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 not be explained, and annotations cover safety. The description supplies usage routing, backend/cache behavior, and most parameter meanings; only max_results semantics remain 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 0%, so the description must carry the burden — and it explains include_snippets, pages, engines (with example values and the empty-chain default), transport modes, and per-call proxy formats. max_results is never mentioned, leaving one of seven parameters undocumented.

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 (быстрый веб-поиск через DuckDuckGo) and what it returns (номера, заголовки, URL). It explicitly distinguishes itself from siblings by naming 'research' and 'paper_search' as different tools.

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?

Uses an explicit Когда / Не когда structure: one query, fact, news, exact URL is the target; 10+ different sites → research, scientific articles → paper_search. The routing decision is fully specified with named alternatives.

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