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

No annotations are provided, so the description carries the full behavioral burden. It discloses caching behavior, rate limiting to avoid captcha, parallel worker pool behavior (≥8 URLs, auto-detected workers, max_parallel override), and the exact return delimiter '--- URL: ...'. It also explains article_only uses Trafilatura.

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 information-dense: purpose is front-loaded, followed by caching/rate-limit/parallel behavior, return format, parameter explanation, a working example, and usage rules. Every sentence adds operational value, 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 4-parameter tool with no annotations and an output schema, the description covers purpose, when and when not to use it, alternatives, return format, concurrency behavior, caching, and parameter semantics via example and inline notes. The only minor gap, exact max_chars semantics, is largely recoverable from the parameter name and example.

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?

With 0% schema description coverage, the description adds real meaning for article_only, max_parallel, and urls, and includes a concrete example. However, max_chars is never explicitly explained beyond appearing in the example, leaving its per-total vs per-URL semantics somewhat ambiguous.

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?

Description opens with a specific action and scope: 'Открывает НЕСКОЛЬКО URL в одном браузере' for deep research across 30-50 sources in one call. It also distinguishes itself from the alternative single-page fetch via the later 'НЕ КОГДА' section.

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 КОГДА/НЕ КОГДА guidance gives concrete triggers: use for 10-50 URLs during deep research, avoid for 1-2 pages (use fetch_page), and if URLs are not yet collected, run research_start, sitemap, or map_site first. This is exemplary routing.

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 provided, the description carries the transparency burden. It states the main behavior — open a URL, click an element, and return the resulting page after the click — and gives concrete element-selection modes. It does not disclose wait behavior, failure behavior, or what happens when multiple elements match, but the core observable behavior is clearly communicated.

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

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

The description is compact, front-loads the main behavior, and uses an example to reduce ambiguity around Russian/English text matching. Every sentence contributes value and 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?

For the main workflow — opening a URL and clicking — it is sufficient: action, element-targeting options, return value, and an example are present. It is incomplete in smaller areas: max_links is unexplained, and there is no guidance on choosing this tool over the related session_click/browser_navigate siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds useful meaning for selector, target_text, and ref, including the example ref="3" and link/button text. However, it completely omits max_links, leaving an optional parameter with no stated purpose or effect.

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

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

The description opens with a concrete verb+resource combination: it opens a URL and clicks on an element. It clearly explains that clicks can target a CSS selector, visible text, or a snapshot ref, which answers the core question of what the tool does. It does not explicitly contrast itself with sibling tools like browser_navigate or session_click, so it stops slightly short of a 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 example browser_click(url, target_text="Продолжить") implies the intended use: supply a URL and an element identifier to perform a one-shot click. It also shows that target_text can be used alone. However, it does not state when to prefer this over session_click, browser_navigate, or session-type tools, nor does it describe when clicking without prior navigation is expected.

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 provided, the description carries the full burden of disclosing behavior. It mentions only the output, not side effects like changing the browser's current page, potential wait times, or error behavior. This is a significant gap for a navigation action.

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 extremely brief, but it is under-specified rather than appropriately concise. It lacks essential details about the tool's operation and parameters, making it insufficiently sized for effective use.

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?

Even with an output schema present, the description omits critical contextual information such as side effects, relationship to siblings, and parameter usage. For a navigation tool with many similar siblings, this is inadequate.

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 does not compensate. While 'first links' hints at the purpose of max_links, it does not explain the parameters or their format. The url parameter is completely undefined in 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 'Page text + first links' gives some indication of what the tool returns, but does not explicitly state that it navigates the browser to a URL. It fails to distinguish from siblings like fetch_page or extract_links, which likely have overlapping functionality.

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 guidance is provided on when to use this tool versus alternatives such as session_navigate or fetch_page. The description offers no context for selecting this tool over others.

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 must carry the burden. It includes the core actions (open, input, return) and notes the returned page is updated. Missing details about failure handling, prerequisites, or side effects, but the description is not misleading and basic behavior 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 description is concise (two sentences) and front-loaded, mentioning the primary action first. It wastes no words but could benefit from slightly turning the purpose claim into a fuller explanation without bloat.

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 simplicity, the description is adequate: it conveys the purpose and primary behavior. The presence of an output schema covers return-format details, so the description reasonably omits those. However, it is thin on potential caveats (e.g., JavaScript dependency, selectors must be visible/animated) that would make it robust.

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 only lists 3 parameters with 0% coverage, forcing the description to clarify meaning. It interprets 'selector' as a CSS selector and 'text' as the input content, but does not describe URL format or specificity. This partial clarification improves on schema but leaves some ambiguity.

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 clearly states the tool opens a URL, types text into a CSS-selector field, and returns the updated page. It specifies the use case (search forms) and distinguishes from sibling tools like browser_navigate (navigation only) and browser_click (click only), making the purpose 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?

The description mentions it is for search forms, giving a clear context for use. However, it lacks explicit when-not-to-use guidance or references to alternative tools like session_type. The instruction is functional but does not frame usage in relation to other available options.

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 supplied, so the description carries the full transparency burden. It does reveal the core algorithm (collect page links, check HTTP statuses, report each with '[404] URL'), which adds useful behavioral context. Missing details such as how redirects are handled, which status codes count as broken dm n-bit, and whether the operation is read-only prevent a higher score.

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 concise, front-loaded with the purpose, and includes a concrete output format. There is no filler or redundancy, and it is well-structured for an agent reading it quickly. It could do more to mention the parameters, but as an efficient summary it is well-built.

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 present output schema covers return shape, but the description itself leaves unexplained the three non-required parameters and does not define the boundary of the tool's scope. An agent must guess what 'internal_only' or 'timeoout' mean in practice. For a 4-parameter tool with zero parameter descriptions and no usage guidance, the narrative is incomplete.

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 input schema has 4 parameters with 0% description coverage and the description does not compensate. Only the 'url' parameter is implicitly covered by gathering 'page links'; timeout, max_links, and internal_only receive no explanation, despite names being partially self-explanatory. A few words on these defaults and effects would materially improve the definition.

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 clearly identifies the purpose with a specific verb and resource: 'Проверка битых ссылок' (checking broken links), then spells out the process and output format ('[404] URL'). The added 'Паттерн broken link checkers' helps distinguish the scope from siblings, though other explicit alternative names are not used.

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 explicit when-to-use or when-not-to-use guidance. It does not reference alternative tools such as extract_links, fetch_page, or crawl, nor does it explain conditions like internal_only or when link checking is preferable. The context is implied only by the type of task.

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 provided, the description carries the full behavioral burden. It discloses a significant side effect: if verification/extracts have not yet run, the tool will autonomously complete them via network/browser. It also states the quality-gate guarantee that sources are live rather than dead.

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

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

The description is compact and front-loads the key purpose and constraints before the WHEN/NOT WHEN routing. Minor redundancy exists ('гейт качества' is mentioned twice), but overall every section 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?

For a single-parameter tool with an output schema, the description covers purpose, usage routing, and important behavioral side effects. It is only missing explicit camp_id semantics, which is a modest gap given the low complexity.

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 required parameter (camp_id), and schema description coverage is 0%. The description never explains what camp_id refers to, how to obtain it, or its expected format; it only implicitly ties it to the DeepResearch campaign context via the tool's purpose.

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 clearly defines the deliverable: a citation pack for report synthesis using only verified sources with extracts in one numbered block. It explicitly contrasts itself with citation_report and research_digest, so an agent can distinguish it from nearby 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?

The WHEN section states to use this tool exclusively when writing a report that needs citations, and the NOT WHEN section names specific alternatives (citation_report for disk files, research_digest for unverified extracts). This is explicit 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?

With no annotations, the description carries the behavioral disclosure burden. It discloses that the tool writes a file to disk, uses a default path of exports/{camp_id}.cit.md when path is omitted, and returns the path and size. It could additionally note overwrite behavior or permission requirements, but it provides substantial behavioral context beyond basic invocation.

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

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

The description is compact and well-structured, front-loading the core outcome and then organizing usage guidance into WHEN and NOT WHEN blocks. Every sentence adds useful information, and the alternative tool is named clearly.

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 simple two-parameter tool with no annotations, the description covers purpose, output location, return value, and when not to use it. It is slightly incomplete on camp_id semantics and path format, but the presence of an output schema and the clear sibling routing make it sufficient 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 compensate. It does explain the path parameter by giving a default path behavior, and camp_id appears in that default path, implying it is the campaign identifier. However, camp_id itself is not explicitly described, and it is unclear whether path should be a directory, a full file path, or a filename.

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 clearly states the tool produces a cited report as a ready-made Markdown file with verified source excerpts, numbering, and a references section. It also explicitly distinguishes itself from citation_pack, so an agent can select it correctly without opening 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?

The description uses explicit WHEN and NOT WHEN sections, stating that this tool is for when a ready cited document file is needed to attach/send/save, and explicitly says to use citation_pack when text is needed for synthesis. This is model guidance for choosing between 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?

With no annotations provided, the description carries the full burden and largely meets it: it discloses the BFS algorithm, max_depth/max_pages limits, internal-link scope, the '--- URL:' output separator, and caching behavior. These are useful operational traits beyond what the bare schema provides.

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?

Core behavior is front-loaded, and the labeled WHEN/NOT WHEN blocks make the description scannable and actionable. The phrase 'Паттерн Firecrawl crawl' is cryptic and adds little, but overall the description is economical and well organized.

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

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

The description covers the algorithm, limits, output format, cache behavior, and alternative tools, and an output schema exists for return details. However, missing semantics for max_chars and article_only are a real gap for a six-parameter tool with no annotations and no inline schema descriptions.

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 explains max_depth and max_pages and hints at pattern, but it never defines max_chars or article_only, both of which are non-obvious and defaulted. The schema only offers names and defaults, so an agent would have to guess those meanings.

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 defines crawl as a BFS traversal of a site from a start page following internal links, with explicit depth/page caps and a text-plus-delimiter output. This clearly distinguishes it from siblings like map_site/sitemap (URL-only) and fetch_page (single section).

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 includes explicit КОГДА and НЕ КОГДА blocks: use crawl for full-site text collection; use map_site/sitemap for URLs only, fetch_page for one section, and sitemap + pattern filtering for huge sites. This is direct routing guidance naming alternatives and conditions.

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 available, the description carries the full behavioral burden. It does disclose the side effect of saving to a file and the default auto path (~/.cache/camoufox-research/exports/), but it does not mention overwrite behavior, file naming, directory creation, or what the tool returns after saving. This is useful but incomplete.

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

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

The description is compact and front-loaded: purpose and formats come first, then path behavior, then a clearly structured WHEN/NOT WHEN section. 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?

The tool is simple and has an output schema, so return value details are not required. The description covers purpose, format choices, path handling, and exclusion cases. Minor gaps remain around file collision/overwrite behavior, but overall it is sufficiently complete for an agent 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 compensate. It explains data as the result from extract/crawl, clarifies that path can be custom or auto-defaulted, and enumerates allowed format values (json/csv/md). It does not describe the exact content expectations for the data string, but the key parameter semantics are meaningfully covered.

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

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

The description states a specific action ('save the result from extract/crawl to a file'), lists the resource and supported formats (json/csv/md), and explicitly contrasts itself with citation_report. This makes the tool's role clear and distinguishable from 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?

The description includes explicit WHEN and NOT WHEN guidance: use it when the result is needed on disk, choose CSV for tables, JSON for automation, MD for reports; do not use it when the result should stay in conversation or when a campaign report is needed. It even names the alternative tool (citation_report).

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 provided, the description carries the full behavioral disclosure burden. It explains the return type (JSON), the two extraction modes, the LLM dependency for llm=True, and the honest 'unavailable' failure response. It also clarifies that llm=True extracts from page text rather than the DOM.

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 dense but well-structured, using WHEN and NOT WHEN headers to organize usage guidance. Every sentence adds operational value: schema formats, selector syntax, mode differences, and exclusions. No filler or redundant restatement of the tool name.

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

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

For a tool with three parameters and no annotations, the description covers all necessary context: schema syntax, selector languages, llm behavior, failure mode, and routing to alternatives. An output schema exists, so detailed return-shape documentation is not required 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%, but the description fully compensates. It documents the schema parameter with concrete JSON examples for CSS, XPath, attributes, and hints; it explains the llm boolean's meaning and default behavior. The url parameter remains self-evident from the tool's purpose.

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 operation: schema-based extraction from a URL, returning JSON. It clearly distinguishes itself from sibling tools by naming fetch_page, batch_fetch, table_extract, and snapshot in its NOT WHEN guidance. The two modes (selector-based and llm=True) are explicit.

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 includes explicit WHEN and NOT WHEN sections. It tells the agent to use llm=True when the page structure is unknown or unstable, and to use alternatives for full text, tables, or when a selector is unknown. This is strong routing guidance relative to sibling tools.

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

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

The tool has no annotations, and the description says only that it 'collects' links. It does not state whether it dereferences URLs directly, whether it only returns raw HTML, what filtering does at the structure level, or any network side effects. The description is under-specified for safe and low-level behavior on a network; the tool can drag the agent.

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?

One concise sentence, front-loaded with the action, directly follows the resource and parameters. No redundancy or 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?

The tool accepts 3 parameters and 1 required; the output schema is present, which helps, but descriptions give no return format or handling. The description is still weak: it fails to note the probable return of a list of URLs, does not cover relative/oblique links, handling of exceptions, or behavior with 'max_links' and limitations. Among sibling drivers, extraction lacks explicit conditions, so the context is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% coverage and no enum values. The description names the url parameter and muddles through the pattern as substring filtering, but it leaves max_links undocumented and gives no format for the pattern or maximum-links semantics. The description fails to compensate for the lack of structured schema data to make a parameter viable.

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 'Collects page links (filter by substring pattern)' clearly identifies a link-extraction verb and resource, and the required 'url' parameter indicates the target page. However, it does not contrast this with sibling tools like web_search or fetch, so some ambiguity about when to choose this over those remains.

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 explicit when-to-use guidance is given, and no alternative tools are mentioned. The filtering behavior is implied but not formalized, leaving it to the agent to infer when link-extraction is preferable to a search, fetch, or browser navigation.

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 the 24-hour cache, the article_only fallback behavior with Trafilatura, and the delta marker behavior for unchanged content. It could also mention max_chars truncation or error behavior, but the main behavioral traits are 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 description is information-dense but tightly organized: main behavior up front, then parameter flags, then clear when/not-when guidance. No filler sentences; each clause adds actionable value.

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-parameter fetch tool with no annotations but an output schema, the description provides strong context: cache, delta behavior, article mode, and routing to sibling tools. The only minor gap is the lack of explicit max_chars semantics, but overall the agent has enough context to call this 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 compensates by explaining article_only and delta in meaningful terms. url is self-evident and max_chars, while not explicitly defined, has a name that makes its purpose clear enough.

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 clearly states what the tool does: return page text stripped of HTML clutter, suitable for articles, docs, and READMEs. It also distinguishes itself from related tools by naming batch_fetch, extract, and session_start as alternatives.

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 and NOT WHEN sections list concrete conditions: use for a single page even JS/SPA, use batch_fetch for 10+ pages, extract for schema-based fields, and session_start for clicks/input. This leaves no ambiguity about when to choose this tool.

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

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

The description discloses key behavioral constraints: it is limited to same-domain links, starts from the start page, and does not read page content. However, because annotations are absent, it leaves other relevant behaviors uncovered, such as network limits, failure modes, or whether any page content/session data is required.

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, scannable, and front-loaded with the primary purpose, before adding the important constraints and the Firecrawl pattern reference. Every sentence adds useful information without repetition.

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 an output schema, so return-value description is not strictly required. Still, the description omits meaningful guidance on parameter behavior and when this tool is preferable to crawl or sitemap, so the agent can make a basic call but cannot confidently choose between this and siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the parameters, but it only indirectly hints at the URL and the pattern concept through 'Firecrawl map'. The max_links parameter is not explained at all, and the pattern parameter is not clearly tied to its behavior.

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 defines a concrete operation: enumerate same-domain links reachable from the start page, explicitly without reading content. It also identifies the behavior as the Firecrawl map pattern, which distinguishes it from sibling tools like crawl, sitemap, and extract_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?

The usage context is implied: use this when you need a lightweight site map of links only, not content. However, no explicit when-to-use or when-not-to-use guidance is given, and no sibling alternatives are named even though several closely related tools exist in the sibling list.

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 disclosure burden. It clearly discloses the cache-vs-fresh comparison, statefulness across visits, and that only changes are surfaced. It does not mention side effects or exactly how the diff is computed, but the core behavioral trait is well 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 description is compact, front-loaded, and well-structured with clear when/not-when sections. The phrase 'Паттерн change detection' is slightly redundant with the opening sentence, but it does not add meaningful bloat.

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, the description does not need to explain return values. It covers the main usage scenarios, exclusions, and the stateful behavior. The main gap is the undocumented max_chars parameter and a lack of detail about what happens when no cache exists, though the first-visit case is addressed in the НЕ КОГДА section.

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 does not mention max_chars at all. The url parameter is only implicitly referenced via 'страницы' (page), and max_chars remains entirely unexplained despite being an optional but meaningful parameter.

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 clearly states a specific verb and resource: it diffs the current page against its previous cached reading and reports what changed. It also differentiates itself from fetch_page by framing the tool as a change-detection pattern, so an agent can distinguish it from 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?

The description uses explicit КОГДА/НЕ КОГДА sections: use it on second and subsequent visits for monitoring, and do not use it on first reads or when a full text version is needed, pointing to fetch_page instead. This is direct, actionable 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?

With no annotations, the description carries the behavioral disclosure burden. It discloses the API sources, that they are free and keyless, the returned fields (year/authors/citations), and a one-day cache. This is substantive transparency for a read-only search tool, though it does not mention rate limits or result pagination.

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 three sentences plus a concrete example. It front-loads the core purpose, then adds return value details, positioning, cache behavior, and invocation example without fluff.

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 three-parameter tool with an output schema and sensible defaults, the description covers the essential operational details: source APIs, no auth keys, return fields, cache, and an example call. The only notable omission is explicit guidance on max_results or how to customize sources, but defaults in the schema make the tool safely callable.

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 partially explains 'query' via the example and 'sources' by naming arXiv and Semantic Scholar, but it does not describe the source parameter format or the max_results parameter at all. The burden is only partially met.

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

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

The description opens with a specific verb and resource: 'Поиск научных статей: arXiv + Semantic Scholar'. It further differentiates itself from general search by framing results as 'первоисточники (tier 0), которых общий поиск почти не видит', which clearly separates it from sibling tools like web_search.

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 clear context for when to use the tool: when searching scientific primary sources with coverage that general web search lacks. It does not explicitly name alternatives or state when not to use it, but the positioning against general search is strong enough for an agent to infer the appropriate use case.

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 are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not mention that loading profile data commonly overwrites the browser's current cookies/localStorage, nor any prerequisites, side effects, or failure 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 a single compact sentence with no filler. It presents the resource and target immediately, which is appropriate for such a simple 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?

The tool is simple and has an output schema, but the description leaves out important behavioral context such as whether this is a state-changing operation, whether existing browser data is replaced, and how a profile is created/loaded. The pairing with profile_save is implied but not explained.

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 description gives the single 'name' parameter meaning: it identifies the profile whose data will be loaded. This compensates somewhat for the 0% schema description coverage, but it does not explain where profiles come from, how the default value behaves, or what happens if the named profile does not exist.

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 a specific action ('Загрузить'), a specific resource ('куки + localStorage профиля'), and a target context ('в живой браузер'). This clearly differentiates it from profile_save and other session tools in the sibling list.

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 'в живой браузер' gives clear context: this tool applies saved profile state to an active browser session. It does not explicitly mention when not to use it, but the intended usage is reasonably evident from the action described.

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 provided, the description carries the full burden of behavioral disclosure. It usefully explains what is saved (cookies + localStorage), from where (live browser), and to where (specific JSON path). It does not address whether the save overwrites/merges an existing profile or what happens if the profile already exists, leaving some behavioral ambiguity.

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

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

The description is compact and front-loaded: the action and purpose appear in the first clause, and the precise file path is added in the second sentence. No filler or redundant 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 single-parameter tool with an output schema known to exist, the description covers the essential invocation details: what is saved, why, and the storage path. It could be more complete by noting overwrite behavior, but an agent already has enough 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?

There is only one parameter and the schema description coverage is 0%. The description gives 'name' concrete meaning by mapping it to the profile name and embedding it in the file path, which is valuable context beyond the bare schema. It only misses explicitly reminding the agent that the parameter has a default value, but the schema already supplies that.

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

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

The description states a specific action ('Сохранить куки + localStorage'), the resource being acted on (the live browser), and the destination profile. This clearly distinguishes it from its sibling profile_load, which is the opposite direction.

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 parenthetical '(логины не терять между сессиями)' implies the use case: persist authenticated state across sessions. However, it does not explicitly state when to call this tool vs. alternatives, nor does it mention profile_load as the restoring counterpart, so an agent must infer the usage context.

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

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

Аннотаций нет, поэтому описание несёт всю нагрузку: оно раскрывает поддерживаемые форматы, зависимость от библиотек pypdf/python-docx/openpyxl, необходимость pip install, а также неспособность читать старые .doc/.xls. Не описано поведение max_chars и возможная обрезка текста, но это второстепенно.

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?

Описание компактное, структурировано по принципу «что делает / когда использовать / когда не использовать». Каждая строка добавляет полезную информацию, нет лишнего текста и повторов.

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 описание даёт достаточно контекста: форматы, источник, альтернативы и ограничения. Не хватает только явного пояснения поведения max_chars и деталей обработки ошибок, но в целом инструмент описан полно.

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?

Покрытие схемы 0%, и описание частично компенсирует это: объясняет, что source — URL или локальный путь. Однако max_chars не упомянут вообще, его смысл остаётся только в имени и значении по умолчанию, поэтому описание не полностью раскрывает параметры.

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?

Описание чётко говорит, что инструмент извлекает текст из PDF/DOCX/XLSX по URL или локальному пути. Это конкретный глагол+ресурс, и сразу же указано отличие от HTML-страниц, что позволяет отличить инструмент от 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?

Приведены явные сценарии КОГДА использовать (документы: отчёты, прайсы, спецификации) и НЕ КОГДА (HTML → fetch_page; старые .doc/.xls → конвертация через libreoffice). Альтернативы названы прямо и по условию, ничего не нужно выводить самостоятельно.

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 provided, the description carries the full behavioral burden and does so thoroughly: it discloses that the server searches per query, deduplicates URLs, returns snippets, caches results for a day, optionally fetches article texts, and can require DEEPSEEK_API_KEY or OLLAMA_HOST for llm_planner. It also clarifies budget-counting behavior, which goes beyond what the schema could convey.

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 well-structured: an intro, a warning, a bulleted parameter breakdown, a concrete example, and when/not-when guidance. Every section earns its place for a 15-parameter tool, though some internal references like 'budget_review.py / research_status' and repeated 'gpt-researcher' pattern mentions add slight redundancy.

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

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

The description is nearly complete for a complex tool: it covers usage scenarios, alternatives, caching, authentication requirements, an example call, and the shape of as_json output. It falls short only by omitting the semantics of max_chars, article_only, and max_parallel, so an agent would have to infer their meaning from names alone.

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 input schema has 0% description coverage, so the description must compensate. It explains most parameters in detail: queries, target_domains, domains_limit, expand, terms_wave, quality_first, fetch_all, as_json, academic, llm_planner, fetch_top, and max_results_per_query via the example. However, max_chars, article_only, and max_parallel are not explained, leaving a small but real 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 description opens with a specific verb and resource: 'Deep-поиск ОДНИМ вызовом — норматив «10 источников» за один ход', making clear this is a deep search that returns deduplicated sources with snippets. It further differentiates from siblings by explicitly stating when research() is not appropriate and pointing to web_search and research_start as alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit КОГДА / НЕ КОГДА section, naming concrete alternatives: use research_start when campaign budget/status tracking is needed, and web_search when only a top-5 result is required. It also warns that this call does not count toward campaign search_calls budget, which is essential for correct tool selection.

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 present, so the description carries the full burden. It explicitly discloses non-mutating behavior ('отчёт НЕ правит — только флагает'), a hard prerequisite (DEEPSEEK_API_KEY or OLLAMA_HOST), the failure mode ('недоступен'), and the output classification labels. This is substantial behavioral context beyond a bare verb.

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 is front-loaded and most sentences carry operational value. However, the sentence about '11-57% ошибок цитирования у коммерческих агентов — мы меряем СВОИ' is promotional noise that does not help an agent call the tool, and the 'канон groundwork/DCM 2026' phrase is opaque jargon.

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

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

For a tool with one parameter and an existing output schema, the description covers the main behavior, result categories, environment requirements, and non-mutation constraint. It lacks a precise definition of camp_id and an explicit when-to-use statement, but an agent can still determine how to invoke it and what to expect.

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 does not compensate. The only parameter, camp_id, is only indirectly tied to 'отчёт кампании'; its format, origin, required type beyond string, and how to obtain a valid value are unaddressed. The parameter name is mildly self-explanatory but the description adds no real semantic 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 description opens with 'КРИТИК-РЕВЬЮЕР' and a concrete pipeline: campaign report → extract 3-5 key claims → verify each against source texts → classify as supported/unsupported/unverifiable. This identifies a specific action and resource, and clearly differentiates it from sibling research_* tools that generate reports or track status.

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 use for post-hoc fact-checking of an existing campaign report, and states it does not correct the report, only flags. However, it never explicitly names alternatives or gives conditions for choosing this tool over, say, research_report or research_status.

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 behavioral burden. It discloses concurrency limits (up to 30 URLs in parallel), cache semantics for max_age, and the meaning of refresh. It could say a bit more about side effects or prerequisites, but the core behavior is well 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 description is dense but not bloated; it front-loads the core purpose, then explains parameters and usage conditions. Some phrasing is repeated, but every sentence provides functional value. The all-caps sections make navigation easy.

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 3-parameter tool with an output schema, the description is complete: it covers purpose, parameter semantics, when to use, when not to use, and alternatives. The availability of an output schema reduces the need to describe return values. No obvious gap remains for an agent to select and 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. It thoroughly explains refresh (rebuild digests and recheck liveness, up to 30 URLs) and max_age (freshness in seconds, 0 = full recheck, 86400 = TTL cache). camp_id is not explicitly defined, but its meaning is inferable from context.

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 clearly states the tool produces short digest packages (title + first paragraph, ~700 chars) plus a liveness status for each source, using a quality gate pattern. It distinguishes itself from siblings by naming citation_report and research_status as alternatives in the 'НЕ КОГДА' section.

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?

Provides explicit 'КОГДА' and 'НЕ КОГДА' sections: use when the campaign is done; do not use when full Markdown is needed (use citation_report) or when the campaign is still running (use research_status/wait). Also explains when refresh is unnecessary for background campaigns.

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 of behavioral disclosure. It does disclose output format (md-table or json), scope (all campaigns), and included fields. However, it does not explicitly state that this is a read-only operation, nor does it mention how the limit parameter affects the result, which is a meaningful behavioral 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?

The description is compact and front-loaded: it opens with the core purpose, then lists fields, then formats, then usage context. Every phrase earns its place; there is no filler or redundant schema repetition.

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 output schema covers return values, so the description does not need to restate them. It provides purpose, scope, fields, formats, and a usage cue. However, the undocumented 'limit' parameter and the 'ALL' wording create a real ambiguity about whether the result is truly complete or truncated by the limit. This is a clear gap for a tool with no annotations.

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 explains 'fmt' by mentioning 'md-таблица или json', but it does not explain 'limit'. Worse, 'ВСЕХ' (ALL) may mislead the agent into thinking the output includes every campaign regardless of the default limit of 50. This is a significant gap and a potential contradiction with the limit parameter.

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 clearly states the tool summarizes ALL campaigns, listing specific fields (id, topic, status, domains/target, updated time). The phrase 'Сырьё для «что мы уже охотили»' distinguishes it from research_report/research_digest as raw index data. This provides a specific resource and scope, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear intended usage: 'Сырьё для «что мы уже охотили»' tells the agent to use this when it needs an overview of previously researched campaigns. It does not explicitly name alternatives or exclusions, but the context is clear enough to route the agent appropriately.

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 full burden. It discloses output format, output content, and a state prerequisite (campaign must be done). It does not explicitly state read-only behavior or failure modes, but a report-generating tool with this level of output detail is reasonably transparent.

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

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

The description is compact, front-loaded with the key purpose, and uses a clear when/not-when structure. Every sentence adds useful information and nothing is redundant.

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 two-parameter schema, existing output schema, and clear sibling routing, the description is complete enough for an agent to select and invoke the tool correctly. It covers purpose, output shape, formatting, and the condition for use.

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 does so by mentioning the two output formats (md table or JSON), which maps to the 'fmt' parameter, and by tying the operation to a completed campaign, which clarifies 'camp_id'. It does not explicitly document valid fmt values or how to obtain camp_id, but the parameter set is small and inferable.

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 clearly states the tool produces a campaign report: a list of sources with title, URL, domain, and class, formatted as an md table or JSON. It also distinguishes itself from nearby siblings by naming citation_pack, research_index, and research_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is explicit with a 'КОГДА' (when) and 'НЕ КОГДА' (not when) section. It states to use this tool when the campaign is done, and provides concrete alternative tools for verified citations, all-campaign summaries, and running campaigns.

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 transparency burden and does it very well. It discloses refusal behavior, the zero-wave honest stop, double-launch race protection, and the synchronous/background execution contract with its marker. These are non-obvious behavioral traits that an agent cannot infer from the schema alone.

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 dense but every clause earns its place: purpose, state constraints, refusal reasons, stop condition, and mode selection. It is front-loaded with the core purpose and does not include redundant 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?

The description covers what the tool does, when it is usable, when it refuses, how it stops, and how to run it synchronously or in the background. Since an output schema is present, return-value documentation is unnecessary, and the operational details are complete enough for an agent 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. It adds meaningful semantics for background by explaining the default is synchronous, that large top-ups should set background=True, and that the agent should wait for the <id>.json marker. camp_id is left at its obvious 'campaign id' meaning, which is acceptable given the tool name and context, though no format or validation hints are provided.

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 clearly states the tool resumes a partial/failed research campaign by filling in missing, distinct sites with fresh angles (tutorial/comparison/case study). It also gives concrete refusal states (done/running), which helps distinguish its role. However, it never explicitly names a sibling alternative like research_start, so full sibling differentiation is missing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool (partial/failed campaigns) and when not to (done or running), including reasons like 'nothing to top up' and the race-condition risk. It also gives execution-mode guidance: synchronous by default, background=True for large top-ups with marker waiting. It stops short of a 5 because it does not compare directly with sibling tools for fresh campaigns.

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 and does so thoroughly: background process with done marker, sqlite progress, partial status, report synthesis pipeline, cron health check, auto-archive, and llm_planner mode. It even warns about double-launch race conditions.

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 dense and front-loaded, with structured WHEN/NOT WHEN sections. It is longer than typical but each sentence adds a distinct operational fact; a few cryptic phrases like 'corner waves' could be clearer.

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 7-parameter tool with no annotations and an output schema, the description covers the full lifecycle: when to launch, how background runs, how completion is signaled, downstream synthesis, failure/partial semantics, and dead-cron warning. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add semantics. It explains feeds as a search-engine-free first leg, queries as optional, background as a separate process with marker, and llm_planner as an LLM layer. However, domains_limit and target_sources are only vaguely tied to 'N sites' and 'unique domains'; topic is left to inference.

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 clearly frames the tool as a research campaign targeting N distinct sites with a progress counter, and explicitly distinguishes it from synchronous research and research_resume. The scope and intent are immediately recognizable.

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 contains explicit КОГДА/НЕ КОГДА (when/when-not) guidance, directing agents to research for synchronous needs and research_resume if a campaign is already running. It also explains when feeds should be used and when queries can be omitted.

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 behavioral burden. It discloses what is returned (status, counter, ranked top sources), the ranking heuristic (docs/code first), and implicitly that it is not exhaustive. It does not explicitly declare read-only-ness, but the status/progress framing makes that clear.

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 compact sections: result content, when to use, when not to use. No filler; the core function is front-loaded and each 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?

The tool is simple (2 params, output schema present), and the description covers what it returns, when to use it, and which siblings to choose instead. Slight incompleteness around the exact role of limit and the definition of 'goal' keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description partially compensates: 'campaign progress' grounds camp_id, and 'top sources' gives limit a meaning (top-N). It does not explicitly state that limit controls the size of the top list or define the counter, leaving some inference to the agent.

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 function: campaign research progress with status, a site-vs-goal counter, and top sources ranked by quality (docs/code first). It also names what it is not via the NOT-WHEN section, distinguishing it from research_report and research_digest.

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?

Provides explicit WHEN guidance ('quick status check') and explicit NOT-WHEN exclusions with named alternatives: full source list → research_report; texts/summaries → research_digest. This fully routes an agent toward the correct tool.

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?

There are no annotations, so the description carries full disclosure burden. It only states the reading of posts; it does not reveal whether it makes a network request, how errors are handled, whether the URL must point directly to the feed, or what the output behavior looks like in edge cases.

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 first two sentences are compact and front-loaded. The last sentence, 'Паттерн RSS scrapers,' is vague and does not add useful detail, earning it not a higher score.

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 does exist, which reduces the burden of describing return values. However, parameter semantics and edge-case behavior in a no-annotation tool are left to the agent, so the definition only minimally supports 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%, and the description adds no explanation of the 'url' parameter or the option 'limit'. It only says that posts come from the feed, leaving the agent to guess at the semantics of of the property names.

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 identifies the URL source (RSS/Atom feed) and the returned data (posts with title, link, and date), making the tool's function recognizable and distinct from web_search or fetch_page. It lacks an explicit action verb, but the meaning 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?

Gives useful targeted use cases: news, blogs, and changelogs in one call. Does not clearly describe when to avoid using this tool or mention alternatives, so the agent gets context but no explicit exclusion 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?

With no annotations, the description carries the behavioral disclosure burden. It transparently explains PNG format, active-tab vs URL modes, selector behavior, Set-of-Mark output with numbered red frames, and the returned file path. The only notable omission is full_page behavior, but that is more of a parameter-semantics gap than a behavioral surprise.

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

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

The description is compact, front-loaded with the core behavior, and uses explicit WHEN/NOT WHEN sections. Every sentence adds operational value and there is 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?

The description covers purpose, usage boundaries, return value, and most parameters, which is solid for a moderately complex tool. However, one of four parameters, full_page, is entirely absent, and its default true could meaningfully affect the screenshot result. Given the 0% schema coverage and no annotations, this is a real completeness 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?

Schema description coverage is 0%, so the description must add meaning. It does explain som, url, and selector in practical terms, but full_page is not mentioned at all despite having a default of true and no schema description. This leaves one important parameter semantically 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 description states a specific action and resource: it captures a PNG screenshot of either the active session tab or a page by URL, and optionally only a selected element. It also differentiates itself from snapshot/fetch_page for text-only needs, so an agent can distinguish it from 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?

Usage is explicitly gated with КОГДА (visual checks: layout, canvas, captcha, images) and НЕ КОГДА (texts/links only), naming snapshot/fetch_page as cheaper alternatives. This gives clear when-to-use and when-not-to-use 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?

With no annotations, the description carries the disclosure burden and does so meaningfully: it states that the tool actually invokes target tools, that dry=True only returns a plan without execution, and that it returns the underlying tool's result rather than a suggestion. It could still mention error/side-effect behavior, but the core execution behavior is explicit.

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

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

The description is compact and front-loaded: it opens with the orchestration pattern, then defines each parameter and the return behavior in a few dense clauses. Every sentence contributes semantic value with no filler or redundant restatement of 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?

For a dynamic router with no annotations and a bare schema, the description covers the essentials: goal selection, query semantics, dry mode, and actual execution behavior. It does not specify error handling or a full goal-to-tool mapping, but the presence of an output schema and the tool's role as a generic dispatcher reduce that 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?

Schema coverage is 0%, so the description compensates by explaining goal as a category word, query as a topic/URL/camp_id parameter, and dry as the plan-vs-execute mode. This adds significant meaning beyond the bare schema, though it stops short of exhaustively mapping goal values to specific target tools.

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 clearly identifies a goal-based service-router: it 'does not hint, but itself calls the needed tool by goal' ('НЕ подсказывает, а САМ вызывает нужный тул по цели'). This is a specific verb+resource description that also distinguishes it from advice/suggestion-style siblings like tool_hint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete goal examples, explains the query parameter, and documents dry mode, giving the agent a clear sense of when to invoke this orchestrator instead of manually selecting a tool. It does not explicitly state when not to use it or name alternatives, but the auto-dispatch behavior is well implied.

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 full burden of behavioral disclosure. It mentions the session_start prerequisite but does not explain what the tool returns, how far back it goes, whether it mutates navigation state, or what happens at the beginning of history.

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 very short and front-loaded, with no wasted words. It earns its place by conveying purpose and a prerequisite, though it could expand slightly on behavior without becoming verbose.

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 single-parameter tool with no annotations and no parameter explanation, this description is insufficient. It correctly identifies the purpose and prerequisite but leaves the tool's behavior and max_chars semantics unexplained, making confident invocation difficult.

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 only parameter, max_chars, has 0% schema description coverage and is not mentioned in the description. The agent cannot infer what max_chars controls, such as output truncation or result size, which is essential for correct invocation.

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 clearly states the action: navigate backward through the session tab history. It uses a specific verb ('back') with a clear resource ('session tab history') and distinguishes itself from sibling navigation tools like session_navigate or browser_navigate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states a prerequisite: 'Requires session_start.' This gives useful context about when it can be used, but it does not mention when not to use it or compare it to alternatives such as browser_navigate or session_navigate.

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?

Since no annotations are provided, the description must carry behavioral disclosure. It does cover the central behavior and its scope ('Действует на активную вкладку'), but it does not describe persistence, reversibility, or how the block interacts with navigation or session lifecycle.

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 and front-loaded with the key operation. The small redundant fragment 'Паттерн request blocking' and a slightly awkward mix of Russian/English keep from being a perfect 5.

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 one-parameter tool with an output schema, the description is reasonably complete: it names the resource, the action, the parameter meaning, and a scope. The only real gap is not specifying the exact pattern syntax or the unblocking path, which would be helpful for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only provides an empty 'pattern' string. The description gives it meaning by explaining that the URL must contain the pattern and providing an example ('analytics', '**.gif'). This compensates well for the 0% schema coverage, although exact glob syntax is not formally documented.

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 clearly states what the tool does: 'Заблокировать запросы, URL которых содержит pattern' (block requests with a URL pattern) and positions it as request blocking. This distinguishes it from navigation/reading tools and from the sibling session_unblock, though it does not name that 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?

Usage is clear enough at a high level: block requests matching a pattern on the active tab. However, there is no explicit guidance on when not to use it, no mention that session_unblock undoes this, and no context about when this is preferable to other sibling tools.

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 full burden. It does disclose the session_start requirement and that it returns text after the click, which is useful. However, it does not disclose possible side effects of the click itself, such as navigation, page reloads, form submission, or any destructive consequences, which is a significant gap for a mutation-like tool.

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

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

The description is well-structured and front-loaded with the core action, followed by return behavior and clear WHEN/NOT WHEN guidance. It is slightly redundant in that 'requires session_start' is restated in the 'no session' exclusion, but overall 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?

For a click tool with no annotations and no schema descriptions, this covers the essential invocation context: session precondition, targeting strategies, return value, and alternatives. It is incomplete only in minor operational details like max_chars semantics and post-click behavior such as waiting for navigation, so it falls short of 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?

The input schema has 0% description coverage, so the description must compensate. It does explain the meaning of selector, target_text, and ref, but it does not mention max_chars, and it does not explain behavior when multiple targeting parameters are provided at once. This is only partial compensation for the missing schema descriptions.

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

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

The description states a specific action ('click') on a specific resource ('live session page') and enumerates three targeting modes: CSS selector, link text, and snapshot ref. It explicitly differentiates the tool from browser_click and snapshot in the 'WHEN/NOT WHEN' block, so an agent can distinguish it from siblings without opening 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?

The description explicitly says when to use the tool ('click on an element of an already open page, session alive') and when not to use it: no session → session_start first, one-time open-click-read → browser_click, need element list → snapshot. This is clear alternative routing with named sibling tools.

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?

There are no annotations, so the description carries the behavioral burden. It discloses the active-tab scope, the message types returned, and the session_start prerequisite. It does not state whether the call is read-only or whether it consumes/clears console messages, but the reading intent is reasonably clear.

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 and front-loaded with the core meaning, and the second sentence adds a valuable prerequisite. It is appropriately concise, though slightly terse.

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-value detail is not needed. The main missing piece is parameter behavior for 'limit', as well as any explicit caution about requiring an active tab/session. It is adequate for a simple console-read tool, but not comprehensive.

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 input schema has a single 'limit' parameter with 0% schema description coverage, and the description does not mention the parameter at all. Since the description is supposed to compensate for low schema coverage, this is a clear gap, even though 'limit' is somewhat self-explanatory.

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 that the tool exposes the JS console messages (error/warning/log) of the active tab, which is a specific resource and function. It is distinguishable from sibling tools like session_network or session_text, though it is phrased as a noun phrase rather than an explicit verb such as 'get'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Требует session_start', giving the key prerequisite for use. However, it does not say when to prefer this over alternatives or when not to use it, leaving some usage context implicit.

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. It transparently states the side effect location (~/.cache/camoufox-research/downloads/), the return value (path), and that selector mode "catches" a download. It does not cover failure behavior or timeout usage, but the core actions and persistence effect are 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 description is extremely compact and front-loaded, with each sentence adding necessary information: the action, parameter meanings, save location, and return value. No filler is present, and the most important usage distinction is placed immediately.

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 that an output schema exists and the tool has only three simple parameters, the description is mostly complete. It covers the purpose, parameter semantics for url and selector, the save directory, and the return value. The only notable gap is the timeout parameter and possibly the relationship between url and selector (alternative vs. combined usage).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It explains two of three parameters well: url is a direct link, selector triggers and catches a download. However, timeout is left entirely unexplained even though it has no schema description; its purpose is only inferable from its name and default of 30.

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 starts with a clear verb and resource: "Скачать файл" (download a file). It clarifies two modes — direct link via url, or clicking a download button via selector — which makes the tool's function distinct from sibling navigation/reading tools. It does not explicitly contrast with any sibling, 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?

The description gives clear context for use: pass a direct link in url, or use selector to trigger and catch a download. This effectively tells an agent when to use each parameter. It does not mention when not to use the tool or name alternatives, so it does not reach 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?

The description discloses a behavioral side effect ('resets state') beyond the name. However, it does not elaborate on consequences such as irreversibility, impact on other sessions, or whether the entire browser closes, and there are no annotations to fill this 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?

The entire description is a single, compact sentence that conveys both the primary action and a side effect without any wasted words.

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 zero-parameter, simple tool with an output schema present, the description covers the essential behavior. It could clarify whether it closes just the current tab or the entire session, but overall it is sufficient.

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?

With zero parameters, the input schema is trivially 100% covered. The description does not need to explain parameter semantics, and the baseline for 0 params is 4.

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 clearly states the action ('closes') and resource ('session tab'), and additionally notes that it resets state. This distinguishes it from sibling tools like session_back or session_status, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention typical scenarios, prerequisites, or exclusions, so an agent must infer usage from the name alone.

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?

Аннотаций нет, поэтому описание несёт основную нагрузку. Оно раскрывает полезные детали: выполнение в MAIN world, возврат JSON и зависимость от session_start. Вместе с этим не сообщается о возможных побочных эффектах выполнения произвольного JS, ошибках или последствиях для страницы; сам факт 'выполнить JS' по крайней мере подсказывает об изменяемости состояния.

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?

Три коротких предложения: основное действие вынесено вперёд, за ним следуют различительный признак, паттерн и обязательное условие. Каждое предложение функционально, без воды и повторов из схемы.

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?

Для одного обязательного параметра описание даёт минимум: суть, место в сессии, выходной формат и предусловие. Не хватает деталей о поведении с асинхронным кодом, границах изоляции и ошибках, поэтому инструмент можно вызвать правильно, но полное видение обработки всё ещё не описано.

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?

Схема задаёт параметр expression как строку без структурного описания, schema description coverage 0%. Описание, однако, привязывает смысл параметра: требуется JS, выполняемый в активной вкладке, и возврат должен быть JSON. Оно не сообщает, как сформировать выражение, должна ли быть сериализуемая строка или как обрабатываются исключения.

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?

Описание называет конкретное действие — выполнить JS, сайт — активная вкладка сессии, мир — MAIN, и явно указывает возврат JSON. Это чётко отделяет инструмент от таких сессионных операций, как session_navigate, session_click или session_type, хотя и без перечисления имён соседей.

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?

Описание указывает предусловие: требуется session_start, что помогает понять, когда инструмент готов к работе. Однако в нём нет явных указаний, когда выбирать этот инструмент вместо высокоуровневых session_таких-ся, или когда использовать именно его, а не другие действия.

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 must carry the behavioral burden. It discloses that it fills all provided fields at once, that submit is clicked if the selector is set, and that session_start is required. However, it does not explain what happens on missing selectors, whether existing field values are overwritten, or how max_chars affects filling — notable for a mutation-oriented tool.

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

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

The description is compact and front-loaded: it starts with the core operation, then defines key parameters, then a prerequisite. It uses a short pattern-list style that is easy to parse, though the Russian wording and lack of formatting boundaries between the parameter hints make it slightly less scannable than it could be.

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 multi-step form-filling tool, the description covers the essential command shape and one prerequisite, and an output schema exists to communicate return values. It omits details like the effect of max_chars, error behavior for invalid selectors, and whether the action fails if any field cannot be filled — leaving an agent to infer some runtime 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?

Schema description coverage is 0%, so the description must compensate. It explains fields as 'JSON {селектор: значение}' and submit as the send button selector — useful. But max_chars is undocumented in both schema and description, leaving one of three parameters unexplained.

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 clearly names the resource and action — 'Заполнить форму' (fill the form) — and the scope 'РАЗОМ' (all at once), which separates it from single-action typing tools like session_type or browser_type. It does not explicitly name a sibling as the alternative, but the intent is not 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?

The description gives a clear usage context — 'Паттерн form filling' and 'Требует session_start' — so an agent knows this is for filling forms in one batch and requires an existing session. It does not explicitly contrast with session_type, session_click, or other alternatives, but the guidance is explicit enough.

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?

There are no annotations, so the description carries the burden of explaining behavior. It discloses that the action runs on the active session tab and requires an existing session, but it does not explain possible side effects of the keys, whether the page state changes, or what the returned result contains.

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, direct, and front-loaded with the action and examples. There is no filler or redundant restating of the tool name.

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 core action and session prerequisite are present, and the output schema reduces the need to explain return values. However, the mysterious max_chars parameter and the lack of any side-effect disclosure keep this from being contextually 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 for the schema. It provides useful semantics for the required key parameter by listing valid keyboard names, but max_chars is completely unexplained. An agent cannot infer why max_chars defaults to 6000 or how it affects this key-press operation.

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 identifies a specific action (press a key), a specific resource (the active tab of a session), and lists concrete accepted key names such as 'Enter', 'Escape', 'Tab', 'ArrowDown', and 'F5'. This clearly distinguishes it from sibling tools like session_click, session_type, and session_scroll.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the prerequisite 'Requires session_start', which is a clear usage constraint. It also signals that the tool is intended for sending special/shortcut keys through the active session tab. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear.

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 must bear the full burden of behavioral disclosure. It only mentions the session_start prerequisite, which is a precondition rather than a behavior. It offers no information about read-only status, output format, error conditions, or side effects.

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 two short sentences with no redundant words or filler. It states the core purpose and a key prerequisite efficiently, achieving high conciseness and front-loading.

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?

Although an output schema exists (so return format is covered), the description is too sparse for a tool with one optional parameter and no annotations. It omits the meaning of max_links and fails to mention any error conditions, edge cases, or how it differs from similar tools. The prerequisite is noted, but the overall context is incomplete.

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 description does not mention the max_links parameter at all, and the schema provides only type and default with no explanatory text. With 0% schema description coverage, the description completely fails to explain the parameter's meaning or usage, leaving the agent to infer it from the parameter name.

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 clearly identifies the resource (links) and context (current session page) but lacks an explicit verb such as 'get' or 'list', making it slightly less direct. It distinguishes from sibling tools like extract_links by specifying the session context, so the purpose is still 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?

The description mentions 'Requires session_start', which implies it should be used after starting a session, but it does not explicitly contrast with alternatives like extract_links or state when not to use it. This provides some context but no direct usage guidance or exclusions.

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 must disclose behavior independently. It mentions that navigation occurs in the current tab without opening a new page and specifies the session_start prerequisite, but it does not clarify side effects (e.g., page content replacement), return behavior, or potential errors. Some transparency exists but is incomplete.

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 extremely concise: two short sentences in Russian that immediately state the core functionality and a key prerequisite. No filler or redundant information is present, and critical information is front-loaded.

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?

Although an output schema exists, it is not shown, so the description must stand on its own. The description omits any mention of return values, waiting behavior, or error handling. For a navigation tool within a session, knowing whether it returns page content or just confirmation is essential. Thus, while the tool is simple, the description is not 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% – neither parameter (url, max_chars) is explained. The description only hints at the URL parameter implicitly through the tool's purpose, but max_chars is completely unspecified, leaving the agent to guess its meaning (likely character limit for response). This fails to compensate for the low schema coverage.

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 clearly states the tool's purpose: navigating to a URL in the current tab of an existing session, explicitly noting that it does not open a new page. This differentiates it from browser_navigate and aligns with session_* 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?

The only usage guidance is the prerequisite 'Requires session_start,' which is useful but does not provide explicit comparison with alternative tools like browser_navigate or explain when to prefer this over other navigation methods. No conditions or exclusions are 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?

No annotations are provided, so the description carries the burden. It usefully declares a dependency on session_start and frames the operation as read-oriented network inspection. It does not disclose limitations such as retention, request body availability, or any side effects, but for a simple inspection tool the disclosed behavior 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?

Three short sentences carry the main object, detail, an AJAX/error signal, the pattern, and a prerequisite. It is front-loaded with the most identifying information and avoids filler. The phrase 'Паттерн network inspection' is slightly redundant but not harmful.

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 single-optional-parameter tool, the description covers the active tab scope, the returned fields, AJAX/error visibility, the required session prerequisite, and the output schema exists to handle return values. Missing 'limit' semantics and explicit alternative guidance keep it from being maximal.

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, 'limit', but schema description coverage is 0% and the description never mentions it at all. The schema title and default value are present, but the agent is not told that limit controls how many recent requests are returned. The description fails to compensate for the schema's lack of parameter documentation.

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 clearly identifies the resource ('active tab network') and the data returned (recent requests with status, method, type, url). It also highlights AJAX and error visibility, which positions the tool as a network inspection tool, distinct enough from the many session_* siblings. It lacks an explicit verb like 'list/get', so not a 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 description gives a clear prerequisite: 'Требует session_start.' It also implies the use case—inspecting recent network requests, including AJAX and errors. However, it does not specify when not to use it or name alternatives like session_status or session_console, so the routing guidance is mostly implicit.

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?

There are no annotations, so the description carries the disclosure burden. It mentions that a prior session_start is required and describes the action, but it does not disclose side effects on the current page/session, error conditions, or whether the resize persists after navigation.

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 extremely terse, front-loaded, and every sentence contributes information: what it does, when it is relevant, and a prerequisite. There is no filler or redundancy.

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 core purpose and session_start prerequisite are present, and an output schema exists. However, with no annotation and no parameter documentation, the agent still cannot correctly infer the meaning and constraints of max_chars, nor does it know the exact behavioral contract beyond 'resize viewport'.

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 does not mention any parameter. Width and height are semantically inferred from 'viewport resize', but max_chars is completely unexplained; the description fails to compensate for the missing schema documentation.

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 clearly states an action ('resize viewport'), identifies the resource ('active tab'), and gives the context ('responsive sites'). This distinguishes it from session navigation, clicking, and other session 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 description explicitly says 'Requires session_start', giving an important prerequisite. It does not explicitly name alternatives or say when not to use it, but among sibling tools there is no other viewport-resize operation, so the guidance is clear enough.

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 full transparency burden. It usefully discloses that the tool waits for lazy content to load ('Ждёт догрузку lazy-контента') and requires session_start. However, it does not explain whether scrolling is incremental or absolute, how max_chars affects behavior, or what happens if the session is no longer active.

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 three short sentences and every sentence earns its place: what the tool does, one behavioral nuance (lazy-content waiting), and a prerequisite. It is front-loaded and has no redundant 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 the return shape may be covered elsewhere. The description adequately captures purpose, prerequisite, and lazy-loading behavior, but the unexplained max_chars parameter and lack of annotations leave a meaningful gap in what an agent needs to invoke the tool 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%, so the prose description must supply parameter meaning. It adds some value by listing 'bottom/top/down/up', which clarifies the direction parameter. However, max_chars is completely unexplained, and the description does not formally map any of its prose to the schema properties, leaving the agent guessing about a key parameter.

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 clearly states the action: 'Скролл на живой странице сессии' (scroll on the live session page) and enumerates the direction values bottom/top/down/up. It distinguishes session_scroll from nearby session_navigate/session_text tools by focusing specifically on scrolling, though it does not explicitly contrast itself with alternative 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 description gives a clear prerequisite: 'Требует session_start' (requires session_start), and scopes the tool to the live session page. It does not state when not to use it or name alternatives, but the context is sufficient for an agent to understand that this tool operates only on an already-started live session.

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 most of the behavioral burden. It does provide the useful prerequisite that a session must already be started, and states it selects by value/label/index rather than by coordinate. It does not describe side effects, errors, or how the selection is applied beyond those basics.

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 two short sentences with no filler. It front-loads the main action and then states the key prerequisite. It earns each word, although it is too brief to support the 0% schema description coverage.

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 small session interaction tool, the description covers the core action and the preconditions, and an output schema exists so the response shape does not need describing. However, it remains incomplete on how the parameters behave, especially selector and max_chars, and on what to do when the session is not active.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the tool description must compensate. It partially clarifies the 'value' parameter by noting that value/label/index are accepted, but it does not clarify how these modes are distinguished, nor what `selector` must contain, nor the meaning of `max_chars`. This is insufficient for the three parameters defined 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 clear action: select an option in a <select> element, and specifies the matching criteria: by value, label, or index. It identifies the resource and behavior well, but it does not explicitly contrast it with sibling tools like browser_click/type or session_click/type.

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 the tool is used when a select-option needs to be chosen in an active browser session and explicitly states the session_start prerequisite. However, it gives no guidance about when to prefer this tool over session_click, session_type, or session_form_fill, so the selection context is only implicit.

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 it does disclose the key behavior: state (scroll, input, clicks) persists between commands and the session lives in a persistent tab until session_end. It does not detail error handling, auth, or resource costs, but it captures the critical stateful trait needed for correct use.

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?

Information is front-loaded and organized with WHEN/NOT WHEN markers. The repeated 'like a human in one tab' phrase is slightly redundant, but the listing of related session_* commands is useful and the overall length is reasonable.

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 stateful browser tool with no annotations, the description covers lifecycle (start, operate, inspect, close), routing, and state persistence. It omits max_chars semantics and behavior on repeated starts, but an output schema exists and the main interaction flow is clear.

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. It references the URL concept but never names the url parameter or explains requirements/defaults. max_chars is entirely absent, leaving one of the two parameters semantically unexplained.

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

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

The description opens with a specific action ('starts a live session') and names the exact resource (persistent tab of serve-worker). It clearly contrasts with fetch_page and browser_click, so an agent can distinguish session_start from its siblings without inspecting 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?

Explicit WHEN/NOT WHEN section: use for interactive stateful operations; use fetch_page for text-only needs and browser_click for one-time URL click. It also lists the follow-up session_* commands and how to close, giving complete 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?

With no annotations, the description must carry behavioral context. It indicates a read-only status check (no mutating actions) and lists the data points (URL, title, tab alive). This is adequate for such a simple query, though it doesn't explicitly state it has no side effects or mention failure modes.

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 a single, concise sentence that fully conveys the tool's purpose. It is front-loaded and free of fluff, earning a perfect score.

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 simple status check with no parameters, the description covers the key output fields (URL, title, tab liveness). It doesn't mention potential edge cases (e.g., what happens if no session exists), but the output schema likely clarifies that. Given the simplicityainer, this is complete enough.

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)Skip. With no parameters to explain, the baseline is 4. The description adds no additional parameter semantics since none exist, which is appropriate. Schema coverage is 100% (vacuously).

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 clearly states the tool reports session status including URL, title, and tab liveness. This is specific and distinct from sibling tools like session_navigate (navigation), session_text (page text), or session_links (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?

The description implies usage for checking session state but does not explicitly mention when to use it instead of other session tools (e.g., session_text for content, session_links for URLs). No exclusion criteria or alternative guidance is provided.

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 transparency burden. It states the prerequisite (`session_start`), the behavior of each operation, and the list fields (`id/url/title`). However, it does not mention side effects such as what happens to the active tab after `close`, whether `new` switches to the new tab, or behavior on invalid `tab_id`.

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

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

The description is compact, front-loaded with the operation list, and has no boilerplate. Each clause maps directly to a parameter or behavior. The only stylized phrase ('as a human') is short and does not harm clarity.

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

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

Given the tool's moderate complexity, the description covers the prerequisite, all operations, and the meaning of every relevant parameter. Since an output schema exists, the description need not restate return details. Minor gaps around invalid states and close/switch edge cases prevent a perfect score.

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 input schema provides zero parameter descriptions, so the description fully compensates. It defines legal `op` values, explains `url` semantics (URL or empty for a blank tab), and maps `tab_id` to both `switch` and `close`. This is exactly the guidance an agent needs to invoke the tool correctly.

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

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

The description states a precise resource (`session_tabs`) and enumerates the exact operations: `list`, `new`, `switch`, and `close`. The phrase 'Несколько вкладок — как у человека' clarifies this is multi-tab session management, distinguishing it from single-tab navigation/click 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?

The description gives clear operational context: `op` selects the action, `url` is for new tabs, `tab_id` is for switch/close, and `session_start` is a prerequisite. It does not explicitly say when to prefer this over `session_navigate`, `session_links`, or `session_status`, but the action-by-action guidance is sufficient.

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 burden. It discloses that a session must be started ('Требует session_start') and clarifies that the tool does not navigate ('без навигации'), which implies a read-only, non-destructive action. However, it does not describe error conditions, return format (though output schema exists), or any side effects. It adds some useful behavioral context beyond the name.

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 a single, compact sentence that front-loads the tool's primary purpose. There is no fluff or redundant wording. It is appropriately sized for a simple tool, though it leaves out optional parameter details. It earns its place but is not overly verbose, so it scores high but not perfect due to missing essential context.

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 simplicity (1 parameter, no annotations) and the existence of an output schema, the description covers the core function and prerequisite. However, it omits any explanation of the max_chars parameter and does not mention what happens if no session is active. While the output schema likely defines the return format, the description is not fully complete for an agent to invoke the tool correctly, especially regarding parameter usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, meaning the description does not explain the parameter max_chars. The parameter name is somewhat self-explanatory, but the description adds no meaning about its purpose, limits, or how it affects the output. With a single parameter and no description, the agent has to guess its semantics, so the description fails to compensate for the lack of schema documentation.

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 clearly states the tool returns the text of the current session page, and the phrase 'без навигации' (without navigation) distinguishes it from navigation-related siblings like session_navigate or fetch_page. The verb is implicit ('get') but the resource is specific. It does not explicitly name alternative tools, but the 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?

The description implies usage: to retrieve the text of the current session page. It also specifies a prerequisite (requires session_start), which is a usage condition. However, it does not provide guidance on when to use this tool versus alternatives like session_links or fetch_page, nor does it mention exclusions. The usage context is implied but not explicit.

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 provided, the description carries the full burden of behavioral disclosure. It only says that input is performed and that session_start is required; it does not mention side effects, error conditions, page state requirements, or what happens with the max_chars limit. The behavioral transparency is thin.

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 two short sentences with no filler. It front-loads the action and then gives the prerequisite. Every sentence contributes useful information, making it appropriately concise.

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