Server Quality Checklist

Tool Scores

• operagx_clear_annotationsA
  4.1/5.0
  Behavior3/5

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

  Annotations already convey idempotency and non-destructiveness. The description adds context about what is removed (badges from map_elements) and the default tab behavior, but it doesn't go beyond that. It is consistent with annotations, but adds only moderate behavioral detail.

  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 compact, uses a clear structure with an Args section and an Example, and is front-loaded with the core action. Every sentence serves a purpose, with no wasted words.

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

  Completeness5/5

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

  For a simple cleanup tool with an output schema and informative annotations, the description covers the mission, the parameters, the use case, and the side effects. It's complete without requiring extra details.

  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 coverage is 100%, so the schema already documents each parameter. The description groups params and notes 'Defaults to the first open tab,' which is somewhat redundant but reinforces the collective selector semantics. It doesn't add significant new meaning beyond the schema.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Removes the numbered overlay badges left behind by operagx_map_elements.' This clearly identifies the tool's function and distinguishes it from siblings, especially as the cleanup counterpart to map_elements.

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

  Usage Guidelines4/5

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

  The description provides a clear use case: 'Use when: you're done visually grounding element ids and want a clean screenshot again.' It also explains the default behavior for tab selection. It doesn't explicitly mention when not to use it, but the context is clear.

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

• operagx_select_optionA
  4.4/5.0
  Behavior4/5

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

  The description discloses error handling behavior (Playwright throws for invalid selector or option) and the return structure with selected values. These go beyond the annotations, which only indicate mutability and destructiveness hints, providing useful context for the agent.

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

  Conciseness5/5

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

  The description is well-organized with clear sections for args, return value, examples, and error handling. Each sentence adds value, and the overall structure is easy to scan.

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

  Completeness4/5

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

  Given the 8 parameters and output schema, the description covers the core selection behavior, tab targeting, return value, and error scenarios. It could be more explicit about the mutual exclusivity of tab targeting parameters, but the schema and description together provide sufficient context.

  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?

  All parameters have schema descriptions (100% coverage), so baseline is 3. The description adds crucial mutual-exclusivity information for value/label/index and clarifies the optional tab selection parameters, which is not fully captured in the schema.

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

  Purpose5/5

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

  The description uses the specific verb 'Chooses' and identifies the resource as 'a native <select> dropdown', and clarifies selection by value, label, or index. This clearly distinguishes the tool from siblings like operagx_click or operagx_type_text.

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

  Usage Guidelines4/5

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

  The description provides an explicit use case in the example ('choose \'Option 2\' from the dropdown') and specifies that exactly one of value/label/index must be used. It implicitly limits usage to native <select> elements, setting boundaries relative to custom dropdowns, but does not explicitly state when not to use it.

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

• operagx_drag_and_dropA
  4.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=false, destructiveHint=true, etc. The description adds valuable behavioral detail beyond that: it clarifies that the drag uses real mouse events (not synthetic) and includes intermediate mousemove steps. This explains the mechanics and potential side effects, which is useful context. No contradiction with annotations.

  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 well-structured with a clear opening, an Args section, a Returns section, and an Example. Every sentence earns its place; there is no fluff or repetition. It is appropriately sized given the tool's complexity.

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

  Completeness5/5

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

  For a tool with 7 parameters, nested objects, and an output schema, the description covers all essential aspects: what it does, why it exists, how to specify targets, what it returns, and a usage example. Since an output schema exists, return values need not be elaborated further, and the example return adds extra clarity.

  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 description summarizes the from/to object structure and explains steps as 'intermediate mousemove steps'. It also provides an example showing how to obtain elementIds via map_elements. While the schema already covers individual parameters (71% coverage), the description adds contextual meaning about how the parameters relate to the drag gesture.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Performs a real mouse-down / move / mouse-up drag between two points or elements'. It also explains the purpose (serving drag handlers relying on genuine mousemove events), which clearly distinguishes it from sibling tools like click, hover, and press_key.

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

  Usage Guidelines4/5

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

  The description gives an explicit 'Use when' example: dragging item A onto the trash icon, and even suggests a workflow with map_elements. However, it does not mention when not to use the tool or name alternative tools for different gestures, so it falls short of a perfect 5.

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

• operagx_press_keyA
  4.5/5.0
  Behavior4/5

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

  The description discloses that a target, if provided, is clicked or focused first — a side effect not obvious from the annotations. It also states the return value {"ok": true}. Annotations already indicate destructive behavior (destructiveHint=true), so additional warnings are less needed. The description adds useful context beyond the structured fields without contradicting them.

  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 well-organized with separate sections for Args and Use when, making it easy to scan. Every sentence adds value, including examples and return type. No fluff or redundancy.

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

  Completeness5/5

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

  Despite having 9 parameters, the description covers the key aspects: what it does, how to specify targets, examples of key syntax, and the behavior when no target is given. Combined with the fully described schema and output schema, the description is complete enough for an agent to select and invoke the tool correctly.

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

  Parameters4/5

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

  Although schema coverage is 100%, the description adds meaning by explaining the key syntax with examples and clarifying the behavior when no target is given ('key goes to whatever currently has focus'). It also notes that elementId is preferred over selector or coordinates, but this is partially echoed in the schema. Overall, the description enhances understanding of parameter usage beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Sends a key or chord to the focused element or page' with concrete examples like 'Enter', 'Escape', 'Control+A'. This specifies the verb (sends), resource (key or chord to element/page), and distinguishes from siblings such as typ_text (which inputs text) or click (which clicks).

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

  Usage Guidelines4/5

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

  The description provides explicit 'Use when' examples, such as 'press Enter to submit the search' and 'select all text in this field', indicating appropriate scenarios. It also explains how targeting works ('If a target is given, it is clicked/focused first'), but does not explicitly mention when not to use the tool or name alternative tools, so it falls 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.

• operagx_hoverA
  4.6/5.0
  Behavior4/5

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

  The description adds behavioral context beyond annotations: it explains that hover is intended to reveal UI elements, returns a hoveredAt object, and explicitly says 'without clicking'. While annotations already indicate non-read-only and idempotent behavior, the description provides valuable context like the side effect of revealing menus and the return value.

  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 well-structured with clearly labeled Args, Returns, and Examples. It is concise, using 'same as operagx_click' to avoid redundancy, and every section earns its place without unnecessary verbosity.

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

  Completeness5/5

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

  Given the tool's complexity (8 optional params, multiple targeting methods), the description is complete: it explains the purpose, the parameter groups, the return value, and a workflow example tying into operagx_map_elements. The output schema further covers return details, so nothing is missing.

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

  Parameters5/5

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

  Although schema coverage is 100%, the description adds critical grouping and exclusivity: 'elementId / selector / x+y: exactly one' and 'tabId / tabIndex / matchUrl / matchTitle (optional)'. This information is not in the schema and clarifies how to select the target and tab.

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

  Purpose5/5

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

  The description clearly states the action: 'Moves the mouse over an element or point without clicking', which distinguishes it from operagx_click. It also specifies the purpose ('to reveal a hover-triggered menu or tooltip'), making the resource and scope explicit.

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

  Usage Guidelines4/5

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

  It provides a concrete when-to-use scenario: 'open the dropdown that only appears on hover' -> hover first, then use operagx_map_elements. It also references operagx_click for targeting semantics, but does not explicitly state when not to use it or list alternatives beyond the example.

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

• operagx_scrollA
  4.6/5.0
  Behavior4/5

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

  Annotations convey non-read-only and non-destructive, but the description adds significant context: it uses a real mouse-wheel event, delta units are CSS pixels, and the exact return shapes differ by mode. This extra detail helps an agent predict behavior without invoking the tool.

  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 well-structured with Args, Returns, and Examples. It is concise, with no filler, and the two examples are practical and directly informative.

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

  Completeness5/5

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

  Despite having 8 optional params and two behavior modes, the description covers tab selection, scroll mode precedence, return values, and example scenarios. Combined with an output schema, it provides a complete picture for an agent to select and call the tool correctly.

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

  Parameters5/5

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

  The schema covers only 50% of parameters with descriptions. The description compensates by grouping tab selectors, explaining the independent roles of elementId/selector vs deltaX/deltaY, and clarifying that delta applies only when no element target is given. This adds essential meaning beyond the schema.

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

  Purpose5/5

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

  The description clearly states it scrolls the page with a real mouse-wheel event or scrolls a specific element into view. The two modes are distinct and well-defined, and the tool is easily differentiated from sibling interaction tools.

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

  Usage Guidelines4/5

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

  Provides explicit conditional guidance: elementId/selector triggers element scrolling, otherwise deltaX/deltaY controls wheel scrolling. Includes practical 'Use when' examples. Does not explicitly name sibling tools as alternatives, but the guidance is clear enough.

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

• operagx_fill_formA
  4.7/5.0
  Behavior4/5

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

  The description adds context beyond annotations by explaining the targeting mechanism (same as operagx_click), the optional submit behavior, and the return structure. Annotations already indicate destructive/read-only, and the description complements rather than contradicts them.

  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 well-structured with sections for args, returns, and examples, and every sentence contributes. It is front-loaded with the core purpose and remains informative without being bloated.

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

  Completeness5/5

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

  Despite the tool's complexity (6 parameters, multiple targeting strategies, optional submit), the description covers all essential aspects: parameters, return format, examples, and alternatives. The output schema further enriches the context, so nothing critical is missing.

  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?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how the fields array works, the targeting options (elementId/selector/x+y), and provides meaningful examples. It goes beyond repeating schema descriptions.

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

  Purpose5/5

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

  The description clearly states 'Fills multiple fields in one call and optionally submits at the end,' which is a specific verb+resource. It also distinguishes itself from siblings by explicitly mentioning operagx_click targeting and contrasting with operagx_type_text for single-field cases.

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

  Usage Guidelines5/5

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

  The description provides explicit when/when-not guidance: 'Use when: log in with username tomsmith and password foo' and 'Don't use when: only one field needs filling — operagx_type_text is simpler.' It also references relevant sibling tools like operagx_map_elements and operagx_click.

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

• operagx_list_tabsA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context: tab IDs are stable for the lifetime of the browser connection, eliminating the need to re-list repeatedly. It also specifies the return format, adding beyond the annotation-only safety profile.

  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 well-structured and front-loaded with the core purpose, followed by a comparison to the base tool, a brief return format, and clear examples. Every sentence earns its place without redundant fluff.

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

  Completeness5/5

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

  Given zero parameters and the return format explicitly shown in the Returns block, the description provides everything needed to invoke and interpret the tool. It also addresses the stable-ID lifetime context, making it complete for this simple list operation.

  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 tool has zero parameters, and the schema is empty (100% coverage by default). The description explicitly states 'Args: none,' confirming the lack of inputs. With no parameters to explain, a baseline of 4 is appropriate.

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

  Purpose5/5

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

  The description states exactly what the tool does: 'Lists every open tab with a stable tabId usable by every other tool in this server.' It uses a specific verb ('lists') and resource ('every open tab'), and clearly distinguishes its purpose from the base list-tabs and interaction siblings.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance: 'Use when: you need to address a specific tab by id' and 'Don't use when: you already have a tabId from a previous call.' It also names the base connector alternative and clarifies when this tool is needed.

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

• operagx_wait_forA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations (readOnly, non-destructive), the description discloses the return value ({ ok: true }), the timeout behavior ('Throws a timeout error naming the selector and state'), and default values for state and timeoutMs. This gives the agent a clear model of runtime 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 well-structured: a summary sentence, Args list, Returns, an Example, and Error Handling. Every section is concise and directly useful, with no filler.

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

  Completeness5/5

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

  For a wait tool with 7 params and an output schema, the description covers all essential aspects: purpose, args, return value, timeout error behavior, and a usage example. It is complete and self-contained for an agent to invoke correctly.

  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?

  Schema coverage is only 57%, and the description compensates by explaining the key parameters: selector, state, and timeoutMs, including defaults and the meaning of tab filters. It adds meaning beyond the schema without repeating every schema field description.

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

  Purpose5/5

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

  The description begins with a clear, specific statement: 'Waits until a selector reaches a given state, or times out.' This identifies the exact verb+resource and the tool's purpose, distinguishing it from sibling action tools like click or type.

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

  Usage Guidelines4/5

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

  It provides a concrete 'Use when' example ('wait for the spinner to disappear before continuing') and explains tab selection via optional args. It lacks explicit exclusions or alternative tool comparisons, so it falls 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.

• operagx_map_elementsA
  4.9/5.0
  Behavior5/5

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

  Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral context: it draws numbered badges on the live page, which can linger in future screenshots unless cleared. It also discloses truncation behavior (totalFound vs count) and the error case when no tabs are open. This goes well beyond what annotations express, especially the side-effect of visual overlays.

  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 well-structured with clear sections (intro, behavior, args, returns, examples, error handling) and is front-loaded with the core purpose. Every sentence contributes meaning, from the workflow hint about calling screenshot next to the error-handling note. Despite its length, it remains scannable and avoids filler. The complexity of the tool justifies the detail.

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

  Completeness5/5

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

  Given the tool's complexity (7 optional parameters, rich output schema), the description is exceptionally complete. It covers return field semantics ('pass this as elementId to other tools', 'truncated to 120 chars'), truncation behavior, tab selection precedence, and error handling when no tabs exist. The output schema already defines the return structure, so the description focuses on behavioral and workflow context, filling all gaps.

  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?

  Schema coverage is 100%, so parameters are already documented. The description adds value by explaining the rationale behind limit (avoid overwhelming context on dense pages), visibleOnly (only what's on-screen), and annotate (draw overlays for the next screenshot). It also clarifies the tab selection fallback ('Defaults to the first open tab'), which supplements the schema's individual property descriptions without redundancy.

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

  Purpose5/5

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

  The description clearly states the tool 'Scans the page for clickable/fillable elements (links, buttons, inputs, selects, ARIA widgets)' and returns them with ids and coordinates. This verb+resource formulation distinguishes it from sibling tools like operagx_click and operagx_type_text, which operate on existing element ids. It also mentions the return structure including CSS selectors and coordinates, making its purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use guidance through examples: 'Use when: "click the login button" -> map_elements first to find its id', and also gives a don't-use case: 'Don't use when... re-resolve selectors instead of re-scanning.' It additionally explains when to increase the limit or use visibleOnly based on page density, and references the workflow of calling screenshot next and clearing annotations when done. This is exemplary usage guidance.

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

• operagx_type_textA
  4.9/5.0
  Behavior5/5

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

  Beyond annotations, the description reveals that it uses CDP Input.dispatchKeyEvent, making JS listeners/IME/masked inputs behave like real typing. It also explains clearFirst's destructive default and delayMs for debounce sites. This adds substantial behavioral context without contradicting the destructiveHint annotation.

  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 well-structured with an intro, Args list, Returns, and Examples. Each section is concise and purposeful, with no fluff or redundancy. The front-loaded intro immediately clarifies the tool's core behavior.

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

  Completeness5/5

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

  For an 11-parameter tool with an output schema, the description covers all necessary aspects: purpose, usage conditions, parameters, return format, and behavioral nuances. It even provides a concrete workflow example with map_elements. The description is fully complete for confident tool selection and invocation.

  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?

  Schema coverage is 100%, so baseline is 3. The description adds value by grouping tab selection params, enforcing 'exactly one' for elementId/selector/x+y, and explaining the purpose of clearFirst and delayMs. This goes beyond the schema's individual descriptions, meriting a 4.

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

  Purpose5/5

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

  The description states a specific verb+resource: focuses an element and types text using real per-character key events. It clearly distinguishes from siblings like operagx_fill_form and emphasizes real typing vs value assignment, so an agent knows exactly what the tool does and how it differs.

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

  Usage Guidelines5/5

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

  The Examples section explicitly provides 'Use when' and 'Don't use when' scenarios, naming operagx_fill_form as the alternative for multi-field form filling. It also references operagx_click for element identification, giving clear contextual guidance.

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

• operagx_clickA
  5/5.0
  Behavior5/5

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

  The description explains that using CDP input triggers native behaviors just like a human click, and details error handling for stale elementIds and missing targets. Annotations already indicate destructive/open-world, but the description adds specific behavioral context and error semantics.

  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 structured with clear sections (Args, Examples, Error Handling) and each sentence adds value. It is detailed but well-organized, front-loading the core purpose and keeping all sections relevant.

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

  Completeness5/5

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

  With 10 parameters and an output schema, the description covers all necessary aspects: return format, error conditions, and alternative tool guidance. It fully equips an agent to select and invoke the tool correctly.

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

  Parameters5/5

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

  The description adds the mutual exclusion rule ('Exactly one of elementId, selector, or x+y must be given') and preference order for elementId, which are absent from the schema. It also clarifies clickCount semantics beyond the schema's default.

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

  Purpose5/5

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

  The description clearly states the tool clicks a real point via CDP mouse input, distinguishing it from JS-level clicks. This specific verb+resource definition differentiates it from sibling tools like operagx_type_text and operagx_hover.

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

  Usage Guidelines5/5

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

  It provides explicit use cases ('click the Submit button', canvas controls) and explicitly warns against using it when typing is needed, directing to operagx_type_text. This exceeds baseline by naming alternatives and giving context.

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