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

No annotations exist, so the description carries the full behavioral burden, yet it only restates the action. It says nothing about what happens when there is no history to go back to, whether it errors, or how it interacts with the browser session.

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

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

A single short, front-loaded sentence with no wasted words. It is efficient, though minimal enough that it borders on under-specification.

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 parameterless navigation tool with no output schema, the description is minimally adequate, but it omits error/edge-case behavior that an agent would need to invoke it reliably.

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

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

The tool takes zero parameters, so the baseline is 4. The description adds no parameter detail, but none is 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?

States a specific action and target: returning to the previous page in a browser-navigation context. An agent can distinguish it from forward-navigation siblings like avito_open, though it does not explicitly name an alternative or contrast itself with 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?

There is no guidance on when to use this versus siblings such as avito_open, avito_click, or avito_scroll. No prerequisites (e.g. needing prior navigation history) are mentioned.

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, and it does disclose one key behavioral trait: irreversible actions need confirm=true. It stops short of explaining what happens if confirm is omitted, whether refs can go stale, or any auth/permission requirements.

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

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

Two tight sentences with no filler; the primary targeting mechanism (ref, marked as more reliable) is front-loaded ahead of the safety caveat.

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-param action tool with no annotations and no output schema, the description covers the essentials but omits failure behavior, return value, and ref invalidation, leaving meaningful gaps an agent would want.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: ref is tied to snapshot output, text to visible labels, and confirm to irreversible actions. The only gap is the precedence when both ref and text are supplied.

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

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

States a specific verb ('кликает') and resource (element) plus the two targeting mechanisms (ref from snapshot or visible text), which distinguishes it from siblings like avito_press and avito_hover. It does not explicitly contrast itself with those siblings, so it falls 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?

Gives useful intra-tool guidance — prefer ref over text because it is more reliable, and irreversible buttons require confirm=true. However, it never says when to use this tool versus avito_press or avito_hover, which is the more important routing decision.

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 burden. It usefully discloses the behavioral consequence (dropdowns appear) and that ref comes from a snapshot, but says nothing about failure modes, whether the element must be visible, or any wait/hover-duration semantics.

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 tightly packed sentence: the action, the parameter source, and the payoff case are all front-loaded with zero waste.

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 one-param action tool with no output schema, the description covers purpose, the parameter's origin, and the typical use case. Only edge-case behavior (missing element, timing) is absent, which is minor here.

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% and the single 'ref' param has no schema description, so the description must compensate. It does partly by identifying ref as coming from the snapshot, but adds no format, syntax, or example for the ref value.

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

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

States a specific verb and resource ('наводит курсор на элемент') and even cites the parameter's origin ('ref из snapshot'). It reads clearly as distinct from the click/press siblings, though it never names them 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?

Gives concrete usage context: hover is how dropdown menus get opened, with the profile menu as an example. No explicit when-not-to-use or named alternatives against siblings like avito_click, so it stops short of a 5.

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 behavioral burden. It implicitly signals a read/extraction operation and discloses the current-page default, which is genuinely useful. It stops short of stating read-only safety, behavior on non-listing pages, or how extraction failures surface.

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

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

Two short sentences, front-loaded with the extracted-field list followed by the default-page rule. No filler, though the long enumeration could read as a list rather than prose.

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

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

With only one parameter and no output schema, the enumerated field list effectively doubles as a return-value description, which is what an agent needs. The main omission is any guidance on when this tool beats the neighboring read/navigation tools.

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

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

Schema description coverage is 0% and the single 'url' parameter is undocumented in the schema, so the description must compensate. 'Без url — текущая страница' fully explains the parameter's nullable default semantics, which is exactly the missing information.

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

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

States a specific verb (разбирает/parses) and resource (объявление/listing) and enumerates the exact fields extracted (заголовок, цена, прайс, описание, адрес, просмотры, продавец, бейджи, ссылки на фото). This clearly separates it from the generic avito_read sibling, though it never names 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?

The clause 'Без url — текущая страница' gives a useful usage hint about default behavior when no URL is passed. However, it never says when to prefer this over avito_read, avito_search, or avito_open, so the agent must infer the routing from the field list 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the return content (cards and tab names) and the special path="" current-page behavior, which is genuinely useful. However, it is silent on auth/profile requirements, whether the call has side effects, and rate limits, leaving gaps for a zero-annotation 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?

Two sentences, front-loaded with the purpose followed by the navigation workflow. No filler. Efficient for the amount of information conveyed.

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 browser-automation read tool with no output schema, the description covers purpose, returned content, and the tab-navigation workflow, which is most of what an agent needs. The residual gap is that no structured fields cover safety or the meaning of the 'path' values.

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 schema documents nothing about 'path'. The description partially compensates by explaining that path="" targets the current page, but it never explains the default '/profile' or what other valid values mean. It adds some meaning but leaves the parameter under-specified.

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 resource and scope: the caller's own listings ('Свои объявления') in the active profile, distinguishing it from generic listing siblings like avito_listing. It also states what is returned (cards and tab names). Clear verb+resource, though sibling differentiation is by implication rather than explicit contrast.

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

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

It gives concrete routing guidance: to open a different tab use avito_click(text=...), and to load the current page call avito_my_items(path=""). This names an alternative sibling and the condition that selects each path. It stops short of stating when not to use the 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?

With no annotations, the description carries the full burden. It discloses only that it 'returns page state' (Возвращает состояние страницы), but says nothing about load-waiting, navigation failures, redirects, or whether existing page state is preserved. That is thin for a navigation 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?

Two short sentences, front-loaded with the action and resource, then the input format and return value. 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 a single-parameter navigation tool with no output schema, the description covers the action, input format, and a rough return. Only navigation/waiting behavior is left unspecified.

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

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

Schema coverage is 0% and the schema only labels the field 'Url', so the description adds real value by specifying it accepts a full address or a path like '/profile'. This meaningfully compensates for the empty schema 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 gives a specific verb ('Открывает' / opens) and resource ('страницу avito.ru'), and the path example clarifies the navigation scope. It is clearly distinguishable from siblings like avito_click or avito_press, though it does not name them 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 implied — you open a page to begin interacting with it — but there is no explicit statement of when to use this versus alternatives such as avito_back or avito_search. No prerequisites or conditions 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?

With no annotations, the description carries the full disclosure burden. It usefully flags that Enter in a messaging context is gated behind confirm=true, but it does not say what a keypress triggers generally (navigation, submission, potential side effects) or how the call behaves outside that one special case.

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

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

Two short, front-loaded sentences with no filler; the core action leads and the caveat follows. The trailing ellipsis in the key list makes the enumeration slightly loose but costs little.

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

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

For a simple two-parameter, no-annotation, no-output-schema keypress tool, the description covers the action, example inputs, and the one safety-relevant constraint. A note on return value or general side effects would make it fully self-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?

Schema coverage is 0%, so the description must compensate and largely does: it illustrates valid values for 'key' and explains the meaning and default behavior of 'confirm' via the messaging-Enter rule. It does not, however, clarify confirm's scope for keys other than Enter.

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

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

States a specific verb (presses) and resource (a keyboard key) and enumerates concrete examples (Enter, Escape, Tab, ArrowDown, PageDown). This implicitly separates it from typing/submitting siblings like avito_type, but it never explicitly names an alternative, so it stops 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?

It gives one conditional rule: 'Enter in messages — only with confirm=true', which tells the agent when confirm is mandatory. However, it offers no general when-to-use guidance versus siblings such as avito_type for text entry, leaving the primary routing decision to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose useful behavior — the source of the list (avatar menu) and that the first entry is the active profile — and implies a read-only listing, but never states that it makes no changes, nor anything about failure modes or return format.

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 clauses, front-loaded with what the tool returns, then the ordering fact, then the alternative. No filler and nothing buried.

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 parameter-less read tool with no annotations and no output schema, the description covers what is returned and the meaningful ordering property, which is enough to call it correctly. Slightly richer detail (e.g. whether names/identifiers come back) would make it fully self-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?

The tool takes zero parameters (schema coverage 100% on an empty property set), so there is no parameter semantics to explain. Baseline 4 applies; nothing is missing that the description could reasonably add.

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

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

States the concrete resource (account profiles taken from the avatar menu), enumerates their kinds (regular, Pro, etc.), and explicitly disambiguates from the sibling avito_switch_profile, which handles switching. An agent can pick between the two without opening a schema.

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

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

The final clause routes the agent to avito_switch_profile for the switching action, which is clear contextual guidance. It stops short of an explicit 'when to use this instead' statement for read/refresh scenarios, but the boundary is unambiguous.

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

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

With no annotations, the description carries the full burden and does disclose useful behavior: wait_for_text blocks up to 15 s, text is returned in chunks via offset/max_chars, and snapshot yields refs (e1, e2…) for later interactions. However, it never covers viewport_only, nor what happens at end-of-page/chunk boundaries, leaving meaningful behavioral gaps for an annotation-free 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?

Three short lines, purpose front-loaded, then mode-specific behavior, each sentence earning its place with no filler. The structure maps cleanly to how an agent would decide between modes.

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 6-parameter, annotation-free read tool with no output schema, the description covers modes, chunking, refs, and the wait timeout, which is close to sufficient. The unexplained viewport_only parameter and the absence of any return-shape or end-of-content note leave it 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?

Schema coverage is 0%, so the description must compensate, and it does explain five of six parameters meaningfully (mode semantics, offset/max_chars chunking, selector as a CSS scope, wait_for_text with its timeout). Only viewport_only is left completely undefined, which is the one gap in otherwise strong 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?

States a specific verb+resource ('Читает текущую страницу') and clearly distinguishes its two output modes, text vs snapshot. It even names the downstream consumers (avito_click, avito_type) of the snapshot refs, which helps an agent place it in the workflow. It does not, however, explicitly contrast itself against non-read siblings like avito_screenshot.

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 explains when each mode applies (visible text vs interactive refs) and when wait_for_text is needed (sections that load after opening), which is real invocation guidance. It stops short of saying when to prefer this tool over alternatives such as avito_screenshot or avito_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 full burden. It usefully discloses two edge cases – replace="" deletes the fragment and drop_empty_line=true removes the emptied line – but omits what happens when 'find' matches nothing (error vs no-op) and whether the target must be focused/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?

Two tight sentences with no filler; the core replacement behavior is front-loaded, followed immediately by the edge-case semantics.

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 mutation tool with no annotations and no output schema, the description covers the operation and parameter edge cases but leaves out failure behavior (no match found) and interaction prerequisites (focus/click), which an agent would need to invoke it reliably.

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?

Despite 0% schema description coverage, the description effectively covers all four parameters: ref is tied to a snapshot, find is the exact fragment, replace documents the empty-string deletion case, and drop_empty_line documents its effect. Only finer details like occurrence matching are left unstated.

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

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

States a specific verb+resource: it replaces one exact text fragment in a field or description editor, explicitly noting it does not touch the rest of the text. This implicitly distinguishes it from the typing-oriented sibling avito_type, though no sibling is named directly.

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 implied by the semantics ('one exact fragment... without touching the rest'), but there is no explicit when-to-use guidance or exclusion versus the closest sibling avito_type, nor any stated precondition such as the field needing focus.

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 burden and does disclose the key side effect: files are downloaded into a folder on disk. However, it omits overwrite behavior, naming/format handling, and any failure or permission caveats, so the behavioral picture is only partial.

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

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

A single dense sentence with no filler, front-loading the action and resource. The trailing purpose clause adds some value but is the least essential part.

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 no annotations and no output schema, the description covers the core action and two of three parameters but leaves 'prefix' and return/error behavior unexplained, so it is adequate rather than 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 coverage is 0%, so the description must compensate. It adds real meaning for 'urls' (avito.st addresses from avito_listing) and 'dest_dir' (a disk folder), but the 'prefix' parameter is never mentioned, leaving one of three parameters undocumented.

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

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

States a specific verb+resource: downloads listing photos to a disk folder, and identifies the input source (avito.st URLs from avito_listing). This clearly separates it from siblings like avito_screenshot or avito_listing itself, though the phrase 'для разбора обложек и галерей' is more intent than scope.

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 mention of 'из avito_listing' implies the tool should be used downstream of avito_listing, which is useful routing context, but there is no explicit when-to-use vs when-not or any stated prerequisite beyond that inference.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It does not disclose the return format (image data, URL, or file path), default capture behavior, required permissions, or any side effects. For a screenshot tool with zero annotation coverage and no output schema, this is a significant gap.

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

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

A single, dense sentence front-loads the core action ('Снимок текущей страницы') followed by the selection condition. No words are wasted, and the structure is appropriately sized for 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?

For a one-parameter screenshot tool with no annotations and no output schema, the description should at minimum clarify what the tool returns (e.g., image blob vs. saved file) and how full_page changes behavior. Neither is covered, leaving key gaps 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?

The schema has one parameter, full_page, with 0% description coverage. The description never mentions this parameter or explains what toggling it does (viewport vs. entire page). With schema descriptions absent, the description fails to compensate, leaving the parameter's effect 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?

Description states a specific verb+resource: 'Снимок текущей страницы' (snapshot of current page). It also hints at differentiation from text-oriented siblings by noting it is for when visual appearance matters ('когда важно, как она выглядит'). However, no sibling is named, so it falls short of the 5-level clarity seen in definitions that explicitly route to 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?

Provides a clear selection condition: use when the visual appearance of the page matters, with concrete examples like covers and layout ('обложки, вёрстка'). It lacks explicit when-not guidance or named alternatives, but the context is sufficient for an agent to decide it is the visual capture tool rather than a text-reading 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?

No annotations are provided, so the description carries the full burden. It does disclose one meaningful behavior: the scroll exists to trigger lazy content loading. That said, it says nothing about side effects, whether the viewport state persists, or what happens at the top/bottom boundaries.

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

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

A single short sentence that front-loads the action before its motivation, with no filler. It is perhaps slightly under-specified rather than padded, but structurally clean.

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 output schema, the description covers purpose but leaves the agent guessing about direction/screens semantics and behavior at scroll limits. Adequate but with visible gaps.

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

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

Two parameters (screens, direction) with 0% schema description coverage, and the description explains neither the magnitude semantics of 'screens' nor the enum values 'top'/'bottom'. With only 50% of parameters even having an enum and no defaults surfaced in the text, the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Прокручивает страницу') plus its purpose ('подгрузки ленты и отзывов'), so an agent can distinguish it from sibling actions like avito_press or avito_click. It does not explicitly name a sibling alternative, which keeps it just below 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 clause 'нужно для подгрузки ленты и отзывов' gives an implicit use condition (call it to lazy-load more feed/review content), which points an agent in the right direction. However, it offers no exclusions, no guidance on when to prefer avito_wait_for_user or repeated scrolling, and no mention of how many scrolls are needed.

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 does disclose the returned card fields (position, price, seller, reviews, promotion), which is useful and not available from any structured field since there is no output schema. However, it omits pagination behavior, auth needs, and rate limits, so the coverage is partial.

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

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

Three short sentences with the purpose front-loaded, then parameter hints, then return shape. No filler, but the parameter hints are not ordered by importance (the required query is never addressed).

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 search tool with no annotations and no output schema, the description covers purpose, two parameters, and the return fields. It still leaves pagination, sorting semantics, price-filter behavior, and the core query parameter undefined, so an agent would need to guess at how several parameters interact.

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 should compensate. It adds real meaning for the two opaque parameters (city as an address fragment, category as a section fragment with a concrete example), but leaves query (the required parameter), page, sort, and both price bounds unexplained — those are inferable from their names, but not 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?

States a specific verb and resource ("Поиск на Авито" = search on Avito), which cleanly separates it from read-oriented siblings like avito_listing or avito_read. It does not explicitly name a contrast tool, so it stops short of a 5, but the intent 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?

There is no statement of when to use this tool versus alternatives such as avito_listing or avito_open, nor any prerequisites. Usage is only inferred from the word "Поиск"; the description provides zero 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 full burden. It discloses a side effect (launching Chrome if needed) and the status fields returned (current page, login, blocking), which is useful. It lacks details on timing, authentication requirements, or what 'blocking' entails, so it is partially transparent 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 a single efficient sentence that front-loads the launch behavior and then the reporting behavior. It is appropriately sized with no filler, though the combined actions make it slightly dense.

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 low complexity, empty schema, and no output schema, the description adequately covers the essential behavior and the main status fields the agent will receive. It could be more explicit about output format or error conditions, but it is largely complete for this simple status tool.

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

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

The tool takes zero parameters, so there is no parameter semantics to convey. The baseline for zero parameters is 4; the description does not need to add parameter 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 clearly states a specific verb and resource: 'launches Chrome window for Avito (if not running)' and 'reports current page, login and blocking'. This distinguishes it from action-oriented siblings like avito_click or avito_open, though it does not explicitly name 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?

Usage is implied: the tool can be called to check status or to ensure the browser is running before other actions. However, there is no explicit guidance on when to prefer this over avito_open or avito_listing, nor any when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses the two visible effects (account switch + cabinet opened), but says nothing about whether the switch persists across other tool calls, what happens to concurrent state, or what occurs on an invalid index. Useful but incomplete for a state-changing operation.

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 sentence, front-loaded with the action and resource, with the parameter's meaning and source tucked into a parenthetical. Zero filler.

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

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

For a one-parameter, no-annotation, no-output-schema tool, the description covers the essentials (what it does, how to obtain the index). It omits error/out-of-range behavior and whether the account switch affects subsequent tool calls, which matters for an agent operating a browser session.

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% and the single 'index' parameter is undocumented in the schema, so the description must compensate — and it does, defining the index as the profile number from avito_profiles with 1 meaning the current profile. It does not state valid bounds or behavior for out-of-range values, so not a 5.

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

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

States a specific verb+resource ('switches account to profile ... and opens its cabinet') and ties the operand to a sibling tool, avito_profiles, so it is distinguishable from navigation siblings like avito_open. It stops short of 5 only because the effect on the session vs. just the view is not fully disambiguated.

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?

Implies usage by stating the index comes from avito_profiles and that 1 is the current profile, which tells the agent where to source the value. It never says when this tool should be preferred over simply opening a page, nor any preconditions or when not to call it.

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

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: submit=true presses Enter and sending a message requires confirm=true, which functions as a safety gate. However, it omits that clear defaults to true (the field is wiped before typing) and says nothing about permissions 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?

Very compact and front-loaded: the core action comes first, then the two behavioral caveats. Nothing is padded, though the fragmentary style loses a little 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?

For a 5-param, 0%-coverage tool with no annotations and no output schema, the description covers the most consequential flags (submit, confirm) but leaves clear and text unexplained and does not describe the return state, so it is only adequately 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 coverage is 0% and there are 5 parameters, so the description must compensate. It explains ref (a snapshot reference), submit, and confirm, but leaves text and clear undocumented, so compensation is only partial.

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

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

States a specific verb+resource: types text into a field, with ref coming from a snapshot. An agent can distinguish this from avito_press and avito_click. It stops short of explicitly naming those siblings 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?

Usage is implied rather than spelled out: the messaging scenario ('в сообщениях это отправка') tells the agent when confirm is needed, but there is no explicit guidance on when to choose this over avito_press or avito_replace_text.

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 burden. It does disclose two behavioral traits beyond the schema: the call blocks until the user acts, and it has a visible side effect of bringing the window to the foreground. It does not disclose what is returned on success vs. timeout, whether the call errors on expiry, or whether the flow state is preserved across the wait.

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

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

Two short sentences, correctly front-loaded with the blocking wait and followed by the foreground side effect. Nothing is padded or 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?

A blocking, human-in-the-loop tool with two undocumented parameters, no annotations and no output schema should say more. Timeout behavior, return/error semantics, and the meaning of the reason modes are all missing, leaving the agent unable to reason about failure or to choose the right reason value.

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 never mentions either parameter. Its wording ('verification or login') loosely maps onto the 'captcha'/'login' values of the reason enum, but the multi-value default of 'any' and the entire timeout_s parameter (including units and default) are left 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 states a specific verb and resource: it waits until the user completes verification or logs in, in a Chrome window. That is unambiguous and clearly unlike the other avito_* interaction tools (click, type, press), but it never names or contrasts an alternative, so it stops 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?

Usage is implied by the scenario it describes ('passes verification or logs into the account'), which tells the agent this is the tool to call when a captcha or login blocks the flow. There is no explicit when-not guidance, no mention of what a caller should do instead, and no statement of what happens if the user never acts.

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