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

With no annotations, the description carries the full burden and does well: it discloses the SSRF guard that blocks internal addresses, that an empty url runs against the current page, that the JS must return a value via `return`, and that the output is page data rather than instructions. Permission/rate-limit and error behavior are still unstated, so not 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?

Short and front-loaded: purpose first, then a labeled 'КОГДА' block, then edge-case notes. Every sentence adds information; only the ExecuteScript reference is somewhat gratuitous if that tool is not a sibling.

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 no explanation. Given that, the description covers purpose, usage, the url default, SSRF constraints, and the return requirement, leaving it essentially complete for a 2-param eval tool.

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 compensate for two undocumented params. It clarifies the empty-default behavior of `url` and the return contract for `js`, which is meaningful, but the `js` parameter's shape/context (what page scope it runs in, what globals are available) is left implicit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: execute the agent's own JS on the page and return the result as JSON. The DOM-extraction/calculation framing makes it distinguishable from fetch_page and web_search. It does not explicitly name a sibling it is not, so it stops short of 5.

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 clear context for when to reach for this tool: pulling fields out of the DOM, computing, extracting data under custom rules. That is real usage guidance, but no explicit when-not or named alternative (e.g. 'use fetch_page for a plain GET') is given.

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

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

With no annotations, the description carries the burden and does disclose a real behavioral trait: internal addresses are blocked by an SSRF guard. It also states the return shape (link text + address). It omits auth requirements, rate limits, and behavior on non-HTML or error pages.

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 short lines, zero filler, front-loaded with the output shape before the routing rules. Every sentence 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, yet the description still sketches them. Routing and the SSRF constraint are covered; the only gap is that the parameters themselves are never addressed, which is the one thing an agent needs to invoke it.

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 two parameters, so the description must compensate. It never mentions 'url' or 'max_links' / its default of 100, leaving the agent to infer how many links are returned and whether the target must be a page or catalog.

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 ('link text + address from a page'), and explicitly distinguishes itself from fetch_page. It does not differentiate from other link-capable siblings such as fetch_many or browser_eval, but the core purpose is unambiguous.

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 / NOT WHEN structure: when to collect sources from a catalog page, and when the agent actually wants page text it should use fetch_page instead. The alternative is named with the condition that selects it.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that each link passes an SSRF guard and that one failed page does not fail the whole batch, which is important operational context. However, it does not state authentication requirements, rate limits, or the read-only nature of the operation explicitly, leaving meaningful behavioral gaps for a network-fetching tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short lines, front-loaded with purpose, then WHEN, NOT WHEN, and a behavioral note. Every sentence earns its place and nothing is repeated unnecessarily.

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?

Usage guidance is complete and output schema exists so return values need not be described. However, for a three-parameter tool with 0% schema description coverage, the description omits parameter meanings and limits, especially max_chars and max_pages, which an agent needs in order to invoke 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 compensate for missing parameter documentation. It only indirectly implies the urls parameter by mentioning links, and says nothing about max_chars or max_pages, both of which have defaults and affect behavior. This leaves two of three parameters undocumented in any human-readable form.

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: reading a batch of pages in one call. It also distinguishes from the sibling tool fetch_page by naming the single-page alternative. An agent can tell exactly what it does and how it differs from 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 / NOT WHEN structure: use when gathering N sources at once, do not use when one page is needed, and route to fetch_page. The condition that selects the alternative is stated plainly with no inference required.

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

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

With no annotations, the description carries the burden and does well: it discloses that rendering happens through a real Firefox (so JS pages work), that `query` switches output from page-head to topic-relevant excerpts, and that an SSRF guard blocks internal addresses — a real operational constraint. It omits rate limits, timeouts, and failure behavior, so not a full 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?

Front-loaded with the outcome, then WHEN / NOT WHEN / parameter note / constraint, each on its own labelled line. No filler sentences; every clause carries decision-relevant 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?

For a 4-param fetch tool with an output schema (so return shape needn't be described), the definition covers purpose, selection criteria, key param behavior, and one hard constraint. The remaining gap — max_chars and the format enum — is the only thing an agent might need to infer.

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 meaningfully explains two of four params (url target, query semantics, and format via 'markdown или чистый текст'), which is above the baseline. However, `max_chars` is never mentioned and format's allowed values are only implied, leaving half the surface 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 (fetch the text of a page) and adds a discriminating implementation detail ('настоящим Firefox', real Firefox, i.e., JS-capable rendering). It distinguishes itself from web_search and, by implication, from link-oriented siblings. An agent can tell exactly what this tool returns: markdown or plain text.

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/НЕ КОГДА structure: use it to read a concrete URL including JS-heavy pages; do NOT use it when what you need is topic-relevant links, in which case route to web_search. The named alternative makes the routing decision 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?

No annotations provided, so the description carries the full burden. It doesn't disclose what happens to existing session cookies, whether loading overwrites state, required permissions, or any error/format behavior. Only the basic mutation operation is implied.

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, front-loaded sentence that states the action, source, and destination without waste. Appropriately sized for a simple operation, though it lacks routing/behavioral detail.

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 tool is simple (1 optional param) and has an output schema, so return values needn't be explained. However, with no annotations and 0% param coverage, an agent lacks the behavioral context (overwrite semantics, path format) needed to call it confidently.

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 'path' parameter defaults to an empty string with no documentation. The description mentions 'from a JSON file' but doesn't explain the path format, whether it's absolute/relative, or what an empty default implies. Partial compensation, baseline-ish.

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 ('Загрузить куки' = load cookies) and target ('в текущую сессию'). It is distinguishable from the sibling 'save_cookies', though it doesn't explicitly name it.

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?

No when-to-use guidance, no prerequisites, no exclusions, and no mention of the complementary 'save_cookies' tool that clearly pairs with this one. The agent gets no routing help.

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?

No annotations are provided, so the description bears the full burden. It explicitly discloses the observable behavior: it returns 'pong'. It implies a no-side-effect check, though it does not discuss failure modes or latency; for such a simple tool this is adequate.

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 one short, front-loaded sentence. Every word contributes, and there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's trivial complexity, zero parameters, and presence of an output schema, the description fully covers the tool's purpose and behavior. Nothing else is necessary.

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 has zero parameters and the schema is empty, so the baseline is 4. The description adds no parameter details, but none are needed.

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 clear, specific action ('Проверка связи' – connectivity check) and its exact result ('возвращает pong'). This unambiguously identifies the tool and differentiates it from all sibling tools, which perform search, research, fetching, or browser automation.

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 phrase 'Проверка связи' provides clear context: this is a connectivity/liveness check. No explicit exclusions or alternatives are stated, but for a zero-parameter health-check tool, this is not a meaningful 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?

No annotations, so the description carries the full burden. It does not say whether an existing file is overwritten, whether it requires an active browser session, whether the write can fail or what the file contents look like. For a filesystem-mutating tool this is a real gap.

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 short sentence with no filler; the action and destination are front-loaded. Nothing to trim.

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 excuses explaining return values, but the definition is thin for its complexity: one undocumented parameter, no annotations, no session/file behavior, and no relation to load_cookies. An agent would have to guess at path semantics.

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?

There is one parameter ('path') with 0% schema description coverage and a default of empty string, yet the description never mentions it. The agent cannot tell from the description what happens when path is omitted, nor what format the path should take.

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?

Specific verb ('save') plus resource ('cookies of the current session') plus output format ('JSON file'). It implicitly contrasts with the sibling load_cookies, but never names it explicitly, so the sibling differentiation is left to inference.

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?

No statement of when to use this tool, when not to, or that load_cookies is the inverse operation for restoring a saved session. The agent gets the what but not the when.

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

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

With no annotations, the description carries the full load and delivers useful behavior: headless Firefox captures the page at FULL height, `width` controls the viewport, and output lands in MARIONETTE_SCREENSHOT_DIR. Missing failure/timeout/auth behavior, but the capture semantics are well 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?

Front-loads purpose, then WHEN, then parameter/environment detail — a sensible order with no filler sentences. Slightly dense multi-clause lines, but each carries distinct 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-value detail is not needed; the description still names the returned file path. For a 2-optional-param visual-capture tool it covers purpose, trigger, parameter semantics and file destination well, leaving only edge-case behavior unstated.

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 and does for both params: empty `url` captures the current page, `width` sets window width with default 1280 and 0 meaning "leave unchanged". Nothing about either parameter is left to guesswork.

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 concrete verb+resource ("PNG-скриншот страницы: вернуть путь к файлу") plus the outcome (file path), so the agent knows exactly what it produces. The "look with eyes" framing implicitly separates it from the text-fetch siblings (fetch_page, fetch_links).

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 a clear use context (visual verification the fetch tools can't provide). No explicit when-not or named alternative, but the trigger conditions are 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?

No annotations are provided, so the description carries the disclosure burden. It reveals what the counters cover (requests, cache, blocks), which is useful, but says nothing about permissions, cost, or freshness of the metrics. An output schema exists, so return structure need not be repeated.

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 short lines with the resource named first and the usage cue second — front-loaded and free of filler. The phrasing 'не гадая' is slightly informal but costs little.

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 no-arg monitoring tool with a full output schema, the description covers the essentials: what the counters measure and when to call it. Only the absence of any contrast with the ping sibling leaves a 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 no parameter meaning to add beyond what the empty schema already conveys.

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 names the concrete resource — server working counters (requests, cache, blocks) — so an agent knows it returns diagnostics rather than performing a fetch. It is clearly separable from siblings like ping and fetch_page, though it never explicitly contrasts itself with 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?

The 'КОГДА' line ('when you want to see how the server is doing, without guessing') implies a diagnostic/monitoring use case, which is reasonable context. However it names no alternative and gives no when-not condition (e.g. vs ping), leaving usage 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?

With no annotations, the description carries the behavioral burden and does so well: it discloses the real-Firefox backend, consensus-based engine aggregation, snippet availability, pagination behavior, and that external text is treated as DATA. It still omits rate limits, authentication needs, and a clear read-only/mutation declaration, so it is strong but not fully complete.

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 short, front-loaded, and clearly ordered: purpose first, then WHEN/NOT WHEN, then behavioral details. Every sentence adds useful information 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?

Given an output schema exists, return values need not be described. The definition covers purpose, usage routing, pagination behavior, and data handling, but it leaves `max_results` undocumented and does not address operational constraints for a no-annotation tool.

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% across 3 parameters, so the description must compensate. It explains `pages` as a pagination control that continues while new links appear, but never explains `max_results`, and `query` gets no meaning beyond the parameter name itself.

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: web search using real Firefox. It distinguishes itself from the sibling fetch_page by naming it as the tool for a different need, so an agent can route correctly 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?

It gives explicit usage guidance with a WHEN clause for fresh topical links and a NOT WHEN clause pointing to fetch_page for the text of a specific page. The alternative is named directly, leaving little to inference.

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