Server Quality Checklist

Tool Scores

• fill_formC
  2.6/5.0
  Behavior2/5

  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 filling a form but doesn't describe how it behaves: e.g., does it submit the form, wait for completion, handle errors, or require specific page states? For a mutation tool with zero annotation coverage, this lack of detail on side effects, permissions, or limitations 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.

  Conciseness4/5

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

  The description is a single, efficient sentence in Russian ('Заполнить форму данными'), which is appropriately sized and front-loaded. It wastes no words, though it could be more informative. Every word earns its place, but the brevity contributes to under-specification rather than optimal clarity.

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

  Completeness2/5

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

  Given the tool's complexity (3 parameters, nested objects, no output schema) and lack of annotations, the description is incomplete. It doesn't explain return values, error handling, or dependencies on other tools (e.g., needing a browser connection). For a form-filling tool in a browser automation context, more detail on behavior and integration is needed to be fully helpful.

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

  Parameters3/5

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

  The description adds no meaning beyond the input schema, which has 100% coverage with clear descriptions for all three parameters (formSelector, fields, tabIndex). Since schema_description_coverage is high, the baseline is 3, as the schema adequately documents parameters without needing extra explanation in the description.

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

  Purpose3/5

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

  The description 'Заполнить форму данными' (Fill a form with data) states a clear verb ('fill') and resource ('form'), but it's vague about scope and mechanism. It doesn't specify whether this is for web forms, UI forms, or other contexts, nor does it distinguish from siblings like 'type' or 'click' which might handle form interactions differently. The purpose is understandable but lacks specificity.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With siblings like 'type' (for inputting text), 'click' (for submitting), and 'wait_for_element' (for form readiness), there's no indication of prerequisites, typical workflows, or exclusions. Usage is implied from the name but not explicitly stated, leaving the agent to guess based on context.

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

• scrollC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but discloses minimal behavioral traits. It mentions scrolling actions but doesn't cover permissions needed, whether it requires a loaded page, error conditions (e.g., if selector not found), or how it interacts with browser state. For a tool with 5 parameters and no annotations, this is inadequate.

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

  Conciseness4/5

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

  The description is a single, efficient sentence in Russian, front-loaded with the core action. However, it could be more structured by explicitly separating the two modes (scroll by direction/distance vs. scroll to element), but it's not wasteful.

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

  Completeness2/5

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

  Given complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't address return values, error handling, or dependencies on other tools like 'connect_to_browser'. For a browser interaction tool with multiple parameters, more context is needed to guide effective use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no meaning beyond the schema—it doesn't explain parameter interactions (e.g., that 'selector' overrides 'direction' and 'distance') or provide examples. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose3/5

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

  The description 'Прокрутить страницу или к элементу' (Scroll the page or to an element) states a general purpose but lacks specificity about what resource it operates on (browser tabs) and doesn't distinguish it from siblings like 'navigate' or 'wait_for_element'. It's vague about whether this is for scrolling within a page or between pages.

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

  Usage Guidelines2/5

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

  No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing an active browser connection (implied by sibling 'connect_to_browser'), nor does it specify scenarios where scrolling is appropriate over other navigation methods. The description alone provides no usage context.

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

• get_attributesC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions 'get' (a read operation) but doesn't disclose behavioral traits like error handling (e.g., if element not found), performance implications, or return format. It's minimal and lacks critical context for safe use.

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

  Conciseness5/5

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

  The description is a single, concise sentence in Russian that directly states the purpose without unnecessary words. It's front-loaded and efficient, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the complexity (a read operation with 3 parameters) and no annotations or output schema, the description is incomplete. It doesn't explain what attributes are returned, how they're formatted, or potential errors. For a tool interacting with web elements, more context is needed for effective use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all parameters (selector, attributes, tabIndex). The description adds no additional meaning beyond what the schema provides, such as examples or edge cases. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose3/5

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

  The description 'Получить атрибуты элемента' (Get attributes of an element) states a clear verb ('get') and resource ('attributes of an element'), but it's vague about the context (e.g., from a web page, DOM) and doesn't distinguish it from siblings like 'get_html' or 'get_text'. It's functional but lacks specificity.

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

  Usage Guidelines2/5

  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 'get_html' (which might include attributes) or 'get_text' (for text content). The description implies usage for retrieving attributes but doesn't specify scenarios, prerequisites, or exclusions.

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

• wait_for_elementC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions waiting for element 'appearance' but doesn't clarify what happens when the element doesn't appear within timeout, whether this blocks execution, what the return value is (success/failure indicator), or error conditions. For a synchronization tool with potential blocking behavior, this represents significant gaps in behavioral understanding.

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

  Conciseness5/5

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

  The description is extremely concise - a single Russian phrase that directly states the tool's function. There's zero wasted language or unnecessary elaboration. While this conciseness comes at the cost of completeness, as a standalone statement it's efficiently front-loaded with the core purpose.

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

  Completeness2/5

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

  For a synchronization tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what constitutes success/failure, what happens on timeout, whether this is a blocking call, or what (if anything) is returned. The agent would need to guess about critical behavioral aspects despite having good parameter documentation in the schema.

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

  Parameters3/5

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

  Schema description coverage is 100%, providing good documentation for all 4 parameters. The description doesn't add any parameter semantics beyond what's in the schema - no examples of selector formats, typical timeout values, or clarification of what 'visible' means in this context. The baseline of 3 is appropriate since the schema does the heavy lifting, but the description adds no compensatory value.

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

  Purpose3/5

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

  The description 'Ждать появления элемента' (Wait for element appearance) states a clear purpose - waiting for an element to appear. It specifies the verb 'wait' and resource 'element', but doesn't distinguish this from potential alternatives like checking for element existence or polling. The Russian translation is clear but lacks specificity about what constitutes 'appearance'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_attributes', 'get_html', and 'get_text' that might retrieve element information, there's no indication whether this tool should be used for synchronization before those operations or as a standalone check. No prerequisites, exclusions, or comparison to similar tools are mentioned.

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

• clickC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behaviors: whether it waits for the element to be clickable, what happens on failure (e.g., timeout), if it triggers page navigation, or what the return value is. For a browser interaction tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's appropriately sized for a simple action tool and front-loads the core functionality.

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

  Completeness2/5

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

  Given this is a browser interaction tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after the click (page change? new tab?), error conditions, or return values. For a tool that could have significant side effects in a browser automation context, more behavioral context is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema (selector for CSS selector, tabIndex as optional tab index). This meets the baseline of 3 when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('кликнуть' - click) and target ('по элементу в указанной вкладке' - on an element in the specified tab). It distinguishes from siblings like hover, key_press, or type by specifying a click action. However, it doesn't explicitly differentiate from other potential click-related tools that might exist in the broader ecosystem.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing to connect_to_browser first), when not to use it (e.g., for non-interactive elements), or how it relates to siblings like hover or wait_for_element. The agent must infer usage from context alone.

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

• connect_to_browserC
  2.9/5.0
  Behavior2/5

  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 states the action is to connect to an already opened browser, implying a setup or initialization step, but doesn't disclose behavioral traits like whether this requires specific permissions, if it's idempotent, what happens on failure, or any rate limits. The description is too vague for a tool that likely involves system interaction.

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

  Conciseness4/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with key details if it were longer.

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

  Completeness2/5

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

  Given the tool likely involves system-level browser connectivity (complexity), no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what happens after connection (e.g., returns a session handle, enables other tools), error conditions, or dependencies, leaving significant gaps for an AI agent to use it effectively.

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

  Parameters3/5

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

  The input schema has 1 parameter with 100% description coverage, documenting the port and default value. The description adds no parameter semantics beyond what the schema provides, as it doesn't mention the port or any other inputs. With high schema coverage, the baseline is 3, and the description doesn't compensate with additional meaning.

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

  Purpose4/5

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

  The description clearly states the action ('Подключиться к' - 'Connect to') and the target resource ('уже открытому Яндекс Браузеру' - 'already opened Yandex Browser'), making the purpose evident. It doesn't explicitly differentiate from sibling tools like 'navigate' or 'list_tabs', which might involve browser interaction, but the focus on connection is specific.

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

  Usage Guidelines2/5

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

  The description provides minimal guidance: it implies usage when a Yandex Browser is already open, but offers no explicit when-to-use rules, alternatives (e.g., vs. opening a new browser), or exclusions. Without context on prerequisites or comparisons to siblings, it lacks actionable usage advice.

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

• evaluateC
  2.9/5.0
  Behavior2/5

  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 states the action but lacks critical details: it doesn't specify if this requires prior connection to a browser (implied by 'вкладке' - tab, but not explicit), what happens on execution errors, whether it returns results, or any security/permission considerations for JavaScript execution. This is a significant gap for a tool that executes code.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to understand at a glance. Every word earns its place.

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

  Completeness2/5

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

  Given the complexity of executing JavaScript in a browser tab (a potentially risky operation), the description is incomplete. With no annotations and no output schema, it fails to address key aspects: it doesn't explain return values (e.g., whether it returns execution results), error handling, dependencies on other tools like 'connect_to_browser', or safety considerations. This leaves significant gaps for an AI agent to use it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear descriptions for both parameters ('script' as JavaScript code and 'tabIndex' as optional tab index). The description adds no additional meaning beyond the schema, such as syntax examples for 'script' or default behavior if 'tabIndex' is omitted. Baseline 3 is appropriate since the schema adequately documents parameters.

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

  Purpose4/5

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

  The description clearly states the action ('Выполнить' - execute) and the resource ('JavaScript код в указанной вкладке' - JavaScript code in a specified tab). It distinguishes from siblings like 'get_console_logs' or 'execute_test' by focusing on direct JavaScript execution rather than testing or logging. However, it doesn't explicitly differentiate from all potential overlapping tools.

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

  Usage Guidelines2/5

  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. For example, it doesn't mention when to use 'evaluate' versus 'execute_test' (which might be for test execution) or 'get_console_logs' (for retrieving logs after execution). There's no context on prerequisites like needing an active browser connection or specific tab states.

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

• execute_testC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'execute test' and 'submit' which implies a write/mutation operation, but doesn't specify permissions needed, whether it's destructive, error handling, or what happens after submission. The description lacks crucial behavioral context for a tool that appears to modify test state.

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

  Conciseness4/5

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

  The description is a single, efficient sentence in Russian that conveys the core functionality. It's appropriately sized for the tool's complexity, though it could be slightly more structured by separating the tab context from the action details.

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

  Completeness2/5

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

  For a tool with 3 required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after submission, what success/failure looks like, error conditions, or how it interacts with the test environment. The description leaves too many behavioral questions unanswered for a tool that appears to perform test execution.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description mentions 'in specified tab' which aligns with tabIndex, and 'select answers and submit' which aligns with testSelectors and submitButtonSelector, but adds no additional semantic context beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('execute test'), the target ('in specified tab'), and the specific operations ('select answers and submit'). It distinguishes from siblings like 'click' or 'fill_form' by focusing on test execution with answer selection. However, it doesn't explicitly differentiate from tools like 'evaluate' which might 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.

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With siblings like 'click', 'fill_form', and 'evaluate' available, there's no indication of prerequisites, appropriate contexts, or when other tools might be better suited for test-related tasks.

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

• get_console_logsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. It states what the tool does but doesn't mention critical aspects like whether it requires an active browser connection (implied by siblings like 'connect_to_browser'), potential performance impacts, or error handling, leaving significant gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the tool's complexity (retrieving browser logs with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral traits, usage context, or return values, which are essential for effective tool selection and invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, with all parameters documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline score of 3 without compensating value.

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

  Purpose4/5

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

  The description 'Получить логи консоли браузера' clearly states the verb ('получить' - get) and resource ('логи консоли браузера' - browser console logs), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_html' or 'get_text' that also retrieve browser content, missing explicit distinction.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_html' and 'get_text' that retrieve different browser data, there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.

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

• get_htmlC
  2.9/5.0
  Behavior2/5

  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 states what the tool does but doesn't describe how it behaves: whether it waits for elements to load, handles errors if selectors don't match, returns raw HTML strings, or requires specific page states. For a tool interacting with a browser, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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

  Completeness2/5

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

  Given the complexity of browser interaction tools and the lack of annotations or output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., HTML string, structured data), error conditions, or dependencies on other tools like 'connect_to_browser'. For a tool with 3 parameters and no structured safety hints, more context is needed.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with clear parameter documentation in Russian. The description adds no additional parameter semantics beyond what's already in the schema, such as explaining the relationship between 'selector' and 'outerHTML' or when 'tabIndex' is needed. This meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the verb ('Получить' - Get) and resource ('HTML содержимое страницы или элемента' - HTML content of a page or element), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_text' or 'get_attributes', which might retrieve different aspects of page content.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'get_text' (for text content) or 'get_attributes' (for element attributes). There's no mention of prerequisites, such as requiring a browser connection via 'connect_to_browser', or when HTML retrieval is preferred over other content extraction methods.

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

• get_page_infoC
  2.9/5.0
  Behavior2/5

  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 what information is retrieved (URL, title, meta-tags) but doesn't describe how it works (e.g., requires an active browser tab, might fail if no page is loaded, returns structured data). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core function and specifies the types of information retrieved, making it easy to understand quickly.

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

  Completeness2/5

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

  Given the complexity of browser interaction tools and the lack of annotations and output schema, the description is insufficient. It doesn't cover behavioral aspects like dependencies on other tools (e.g., 'connect_to_browser'), error conditions, or the format of returned data. For a tool in this context, more detail is needed to be complete.

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

  Parameters3/5

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

  The schema description coverage is 100%, with the parameter 'tabIndex' documented as 'Индекс вкладки' (tab index). The description doesn't add any meaning beyond this, such as explaining what happens if no tabIndex is provided or how tabs are indexed. With high schema coverage, the baseline score of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Получить информацию о странице (URL, заголовок, мета-теги)' translates to 'Get information about a page (URL, title, meta-tags)'. This specifies the verb ('get information') and resource ('page'), though it doesn't explicitly differentiate it from siblings like 'get_html' or 'get_text'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a browser connection), exclusions, or comparisons to siblings like 'get_html' (which might retrieve raw HTML) or 'get_text' (which might extract visible text).

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

• hoverC
  2.9/5.0
  Behavior2/5

  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. While 'hover' implies a non-destructive action, the description doesn't specify whether this triggers UI events, requires the element to be visible, has timing considerations, or what happens if the selector fails. This leaves significant gaps in understanding the tool's behavior.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's action without any wasted words. It's front-loaded and appropriately sized for a simple operation, earning full marks for conciseness.

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

  Completeness2/5

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

  Given the tool's complexity (interactive UI action) and lack of annotations or output schema, the description is insufficient. It doesn't explain what hovering achieves (e.g., triggering events), success/failure conditions, or integration with sibling tools like 'wait_for_element'. For a browser automation tool with no structured behavioral hints, more context is needed.

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

  Parameters3/5

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

  The schema has 100% description coverage, with clear documentation for both parameters ('selector' as CSS selector, 'tabIndex' as tab index). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced parameter understanding.

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

  Purpose4/5

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

  The description 'Навести курсор на элемент' (Hover cursor over element) clearly states the action (hovering) and target (element), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar sibling tools like 'click' or 'wait_for_element' in terms of when hovering is specifically needed versus clicking or waiting.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'click', 'wait_for_element', and 'get_attributes' available, there's no indication of when hovering is appropriate (e.g., for triggering dropdowns or tooltips) versus when other actions might be better suited.

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

• key_pressC
  2.9/5.0
  Behavior2/5

  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 states the action but doesn't explain what happens after pressing (e.g., whether it triggers events, waits for effects, or has side effects like focus changes). For a tool that simulates user input, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for its purpose.

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

  Completeness2/5

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

  Given the complexity of simulating keyboard input and the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, interaction with web elements, or return values, leaving the agent with insufficient context for reliable use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents the parameters (key, modifiers, tabIndex). The description adds no additional meaning beyond what's in the schema, such as examples of key combinations or when to use tabIndex. Baseline 3 is appropriate as the schema handles the heavy lifting.

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

  Purpose4/5

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

  The description 'Нажать клавишу или комбинацию клавиш' clearly states the action (press) and target (key or key combination) in Russian, making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'type' or 'click', but the verb 'press' is specific enough to convey the core function.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'type' (for text input) or 'click' (for mouse actions). It lacks context about typical use cases, such as keyboard shortcuts or navigation, leaving the agent to infer usage from the tool name alone.

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

• navigateC
  2.9/5.0
  Behavior2/5

  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 states the basic action but lacks critical behavioral details: it doesn't specify if this requires an existing browser session, what happens on navigation failure, timeouts, or authentication needs. For a navigation tool with zero annotation coverage, 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.

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's purpose. It's front-loaded with the core action and has zero wasted words, making it highly concise and well-structured.

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

  Completeness2/5

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

  Given the tool's complexity (navigation with multiple parameters) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, dependencies on other tools (e.g., connect_to_browser), or what happens post-navigation, leaving significant gaps for an AI agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters (url, tabIndex, waitForSelector). The description implies navigation to a URL in a tab but adds no syntax, format, or usage details beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Перейти по URL' - navigate to URL) and the target resource ('в указанной вкладке' - in the specified tab). It uses specific verbs and identifies the resource, though it doesn't explicitly differentiate from sibling tools like 'connect_to_browser' or 'list_tabs' which might have related functionality.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active browser connection), exclusions, or compare it to sibling tools like 'connect_to_browser' for setup or 'wait_for_element' for post-navigation actions.

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

• screenshotC
  2.9/5.0
  Behavior2/5

  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 states what the tool does but doesn't describe important behavioral aspects: whether it requires browser connection first, what format the screenshot is saved in, where it's saved, error conditions, or performance implications. For a tool with 4 parameters and no annotation coverage, this is insufficient.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that immediately communicates the core functionality. There's no wasted language or unnecessary elaboration - every word serves the purpose of explaining what the tool does.

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

  Completeness2/5

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

  For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, where screenshots are saved, what formats are supported, or any error handling. The description alone is insufficient for an agent to understand the full context of using this tool effectively.

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

  Parameters3/5

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

  The schema has 100% description coverage, with all parameters clearly documented in Russian. The description doesn't add any additional parameter context beyond what's already in the schema. According to scoring rules, with high schema coverage (>80%), the baseline is 3 even with no parameter information in the description.

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

  Purpose4/5

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

  The description clearly states the action ('Сделать скриншот' - 'Take a screenshot') and the target ('указанной вкладки' - 'of the specified tab'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential screenshot-related alternatives among the sibling tools, which include various browser interaction tools but no obvious screenshot alternatives.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. Among the sibling tools, there are several browser interaction tools (click, navigate, get_html, etc.), but no explicit comparison or context for choosing screenshot over other methods of capturing page content is provided.

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

• typeC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions entering text in a field on a tab, but doesn't disclose behavioral aspects like whether it simulates human typing (implied by 'delay' parameter), error handling, or interaction effects. The description is minimal and lacks operational context.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded with the core action.

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

  Completeness2/5

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

  Given no annotations and no output schema, the description is insufficient for a tool with 4 parameters and browser interaction complexity. It doesn't explain return values, error conditions, or behavioral nuances like how it interacts with tabs and fields, leaving significant gaps for an AI agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional semantic information about parameters beyond implying text entry in a tab context. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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

  Purpose4/5

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

  The description clearly states the action ('Ввести текст' - 'Enter text') and target ('в поле в указанной вкладке' - 'in a field on the specified tab'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'fill_form' or 'key_press', which may 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.

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'fill_form' or 'key_press'. It states what the tool does but offers no context about appropriate use cases, prerequisites, or exclusions.

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

• get_textB
  3.1/5.0
  Behavior2/5

  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 tool retrieves text content but doesn't mention potential behaviors like error handling (e.g., if the selector doesn't exist), performance considerations, or what happens with dynamic content. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's purpose without any unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.

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

  Completeness3/5

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

  Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output format. Without annotations or an output schema, more information would be helpful for an agent to use it effectively, but it meets a bare minimum.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with clear documentation for both parameters ('selector' and 'tabIndex'). The description adds no additional semantic information beyond what's in the schema, such as examples or edge cases. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Получить текстовое содержимое страницы или элемента' (Get text content of a page or element). It specifies the verb ('получить' - get) and resource ('текстовое содержимое' - text content), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_html' or 'get_attributes', which reduces it from a perfect score.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_html' (which might return HTML markup) or 'get_attributes' (which retrieves element attributes), nor does it specify scenarios where this tool is preferred. Usage is implied by the purpose but not explicitly stated.

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

• list_tabsB
  3.1/5.0
  Behavior2/5

  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 states the tool retrieves a list but doesn't disclose behavioral traits such as whether it requires an active browser session, potential errors if no tabs are open, or the format of the returned data. The description is minimal and lacks essential operational context.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Russian that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for its purpose.

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

  Completeness2/5

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

  Given the tool's complexity (simple retrieval) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the returned list looks like (e.g., structure, data types) or any dependencies (e.g., requires browser connection). For a tool with no structured support, more context is needed to be fully helpful.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied as it correctly avoids redundancy, though it doesn't compensate for any gaps (none exist).

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Получить список всех открытых вкладок с их индексами и заголовками' (Get a list of all open tabs with their indices and titles). It specifies the verb (get/list) and resource (open tabs), though it doesn't explicitly differentiate from siblings like 'get_page_info' which might overlap in functionality. The description is specific but lacks sibling comparison.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., browser connection required), or exclusions. Given sibling tools like 'get_page_info' that might retrieve similar information, the lack of differentiation leaves usage unclear.

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