Provides browser interaction tools for Opera GX, including clicking, typing, form filling, option selection, drag-and-drop, scrolling, and element mapping, by attaching to a running Opera GX instance via the Chrome DevTools Protocol.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@operagx-connector-plus Click the search box and type 'operagx-connector-plus'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that adds real browser interaction — click, type, keyboard,
form-fill, drag, scroll, select — on top of the read-only OperaGX connector
(go-to-page, list-tabs, tab-content, screenshot, close-tab,
history). Run both MCP servers side by side; this one doesn't replace the
original, it fills the gap between "read the page" and "act on it."
Two ways exist to make an agent actually click/type in a browser:
OS-level hardware events (SendInput on Windows, robotjs,
xdotool) — simulate input at the operating system, blind to window
coordinates, steal the real mouse cursor, need the window focused and
on-screen, and need OS accessibility permissions.
Chrome DevTools Protocol (Input.dispatchMouseEvent /
Input.dispatchKeyEvent) — simulates input inside the browser's own input
pipeline. Indistinguishable from real hardware input to the page (unlike
element.click()/dispatchEvent() in JS, which skip native browser
behavior and are trivially detectable by sites), works in the background,
doesn't touch the real OS cursor, and needs no extra OS permissions.
Since Opera GX is Chromium-based, it already speaks CDP. This server uses
playwright-core purely as
a typed CDP client (chromium.connectOverCDP) — no Playwright-managed
browser is launched; it attaches to your existing, already-running Opera GX.
Related MCP server: Opera DevTools MCP
npm install
npm run buildRequires Node.js 18+.
Launch Opera GX with a remote debugging port. Add a flag to wherever you launch it from:
--remote-debugging-port=9222This applies to a shortcut's target, a Run-at-login entry, or any
launcher — see docs/enabling-cdp.md for exact
steps on Windows (taskbar pin, Start Menu shortcut, autostart registry
entry).
Register the server with your MCP client. For the Claude Code CLI, at user scope (available in every project):
claude mcp add operagx-connector-plus -s user \
-e OPERAGX_CDP_URL=http://localhost:9222 \
-- node /absolute/path/to/operagx-connector-plus/dist/index.jsFor other clients, the equivalent JSON config is:
{
"mcpServers": {
"operagx-connector-plus": {
"command": "node",
"args": ["/absolute/path/to/operagx-connector-plus/dist/index.js"],
"env": { "OPERAGX_CDP_URL": "http://localhost:9222" }
}
}
}Also register the base OperaGX connector (screenshot, tab-content, go-to-page, ...) — this server is designed to complement it, not replace it. See the section below for the recommended combined workflow.
This server pairs with the base connector's screenshot tool for visual
grounding ("set-of-marks" style):
operagx_map_elements — scans the DOM for clickable/fillable elements,
returns each with a small integer id, role, text, and coordinates, and
draws numbered badges on the live page.
Call the base connector's screenshot tool — the badges let you visually
confirm which numbered id is which element.
operagx_click / operagx_type_text / operagx_fill_form /
operagx_select_option / operagx_drag_and_drop / etc., addressed by
elementId (preferred), a raw CSS selector, or absolute x/y
coordinates.
operagx_clear_annotations when done, so badges don't linger in future
screenshots.
Tool | Does | Read-only | Idempotent |
| Enumerate tabs with a stable | ✅ | ✅ |
| Map clickable/fillable elements to numbered ids + coordinates, annotate the page | ✅ | — |
| Remove the numbered overlay badges | — | ✅ |
| Real CDP mouse click (left/right/middle, single/double/triple) | — | — |
| Move the mouse over an element/point | — | ✅ |
| Focus + type real per-character key events | — | — |
| Send a key or chord ( | — | — |
| Fill multiple fields in one call, optional submit key | — | — |
| Choose a | — | ✅ |
| Real mouse-down → move → mouse-up drag | — | — |
| Mouse-wheel scroll, or scroll an element into view | — | — |
| Wait for a selector to reach a state (visible/hidden/attached/detached) | ✅ | ✅ |
Every tool accepts an optional tab selector (tabId, tabIndex, matchUrl,
matchTitle); omitting it defaults to the first open tab. Every tool also
declares MCP annotations (readOnlyHint, destructiveHint, idempotentHint,
openWorldHint) and a structured outputSchema, so clients that support
structuredContent get typed results, not just text.
evaluations/eval.xml has 10 read-only, verifiable
QA pairs for testing whether an LLM can use this server effectively, following
the MCP evaluation guidelines. Since this
server deliberately has no navigation tool (that's the base connector's job),
each question assumes both servers are available, exactly as described above.
This server can act on whatever page is open — treat it like giving a script mouse/keyboard access to the browser. Don't point an autonomous agent at a tab with an authenticated session you don't want touched.
There is no execute-script/arbitrary-JS tool by design, to keep the
attack surface to well-defined interaction primitives.
CDP is unauthenticated by default on localhost — don't expose the
debugging port beyond localhost/a trusted network. This server binds
outbound to whatever OPERAGX_CDP_URL you configure; it does not open any
listening port itself.
All inputs are validated with Zod .strict() schemas
before any tool executes.
npm run dev # tsc --watch
npm run build # one-shot build to dist/
npx @modelcontextprotocol/inspector node dist/index.js # interactive testingSee CONTRIBUTING.md.
Removes the numbered overlay badges left behind by operagx_map_elements.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab to clear. Defaults to the first open tab.
Returns: { "ok": true }
Examples:
Use when: you're done visually grounding element ids and want a clean screenshot again.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes |
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.
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.
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.
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.
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.
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.
Clicks a real point in the browser via CDP mouse input (Input.dispatchMouseEvent), not a JS-level element.click(), so native behaviors (custom canvas controls, drag handles, popups, focus/blur listeners) fire exactly as they would for a human click.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab to click in.
elementId (number, optional): id from the last operagx_map_elements call. Preferred.
selector (string, optional): CSS selector, if not using elementId.
x / y (number, optional): absolute viewport coordinates, if not using elementId/selector.
button ('left' | 'right' | 'middle', default 'left').
clickCount (number, default 1): 2 for double-click, 3 for triple-click.
Exactly one of elementId, selector, or x+y must be given.
Returns: { "ok": true, "clickedAt": { "x": number, "y": number, "selector"?: string } }
Examples:
Use when: "click the Submit button" -> map_elements first for its elementId, then click it.
Use when: a canvas-drawn control has no DOM selector -> click with explicit x/y from a screenshot's pixel coordinates.
Don't use when: you need to type into a field afterward and haven't focused it yet — use operagx_type_text instead, which clicks and types in one call.
Error Handling:
Returns "elementId N is not in the current map..." if the id is stale — call operagx_map_elements again.
Returns "Provide one of: elementId, selector, or x/y." if no target was given.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Absolute viewport x in CSS pixels, if not using elementId/selector. | |
| y | No | Absolute viewport y in CSS pixels, if not using elementId/selector. | |
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| button | No | left | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| selector | No | CSS selector, if not using elementId. | |
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| elementId | No | Id from the last operagx_map_elements call (preferred — most robust). | |
| clickCount | No | 2 for double-click, 3 for triple-click. | |
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| clickedAt | Yes |
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.
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.
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.
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.
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.
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.
Performs a real mouse-down / move / mouse-up drag between two points or elements, so drag handlers relying on genuine mousemove events (sortable lists, sliders, canvas handles) receive the motion they expect.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab.
from / to: each { elementId? | selector? | x?+y? }, identifying the start and end points.
steps (number, default 10): intermediate mousemove steps between from and to.
Returns: { "ok": true, "from": { "x": number, "y": number, "selector"?: string }, "to": { "x": number, "y": number, "selector"?: string } }
Examples:
Use when: "drag item A onto the trash icon" -> map_elements for both elementIds, then drag_and_drop from item A's id to the trash icon's id.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| steps | No | Intermediate move steps, for drag handlers that need motion events. | |
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| to | Yes | |
| from | Yes |
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.
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.
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.
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.
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.
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.
Fills multiple fields in one call and optionally submits at the end. Each field targets an element the same way as operagx_click (elementId/selector/x+y).
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab to fill.
fields (array, min length 1): each item is { elementId? | selector? | x?+y?, value: string }.
submitKey (string, optional): e.g. "Enter" to press after the last field. Omit to skip.
Returns: { "ok": true, "fields": [ { "filledAt": { "x": number, "y": number, "selector"?: string }, "value": string } ] }
Examples:
Use when: "log in with username tomsmith and password foo" -> map_elements for both field ids, then fill_form with both, submitKey="Enter".
Don't use when: only one field needs filling — operagx_type_text is simpler for that case.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| fields | Yes | Fields to fill, in order. | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| submitKey | No | e.g. "Enter" to press after the last field. | |
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| fields | Yes |
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.
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.
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.
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.
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.
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.
Moves the mouse over an element or point without clicking, e.g. to reveal a hover-triggered menu or tooltip before interacting with it.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab to hover in.
elementId / selector / x+y: exactly one, same as operagx_click.
Returns: { "ok": true, "hoveredAt": { "x": number, "y": number, "selector"?: string } }
Examples:
Use when: "open the dropdown that only appears on hover" -> hover over its trigger element first, then operagx_map_elements to find the newly-visible items.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Absolute viewport x in CSS pixels, if not using elementId/selector. | |
| y | No | Absolute viewport y in CSS pixels, if not using elementId/selector. | |
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| selector | No | CSS selector, if not using elementId. | |
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| elementId | No | Id from the last operagx_map_elements call (preferred — most robust). | |
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| hoveredAt | Yes |
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.
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.
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.
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.
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.
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.
Lists every open tab with a stable tabId usable by every other tool in this server.
This complements the read-only list-tabs from the base OperaGX connector: that one is for
reading; this one hands you the id format the interaction tools (operagx_click, operagx_type_text,
operagx_map_elements, ...) expect in their tabId parameter.
Args: none.
Returns: { "tabs": [ { "tabId": string, "url": string, "title": string, "index": number } ] }
Examples:
Use when: you need to address a specific tab by id instead of relying on the default (first open tab).
Don't use when: you already have a tabId from a previous call in this session — ids are stable for the lifetime of the browser connection, no need to re-list before every action.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tabs | Yes |
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.
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.
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.
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.
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.
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.
Scans the page for clickable/fillable elements (links, buttons, inputs, selects, ARIA widgets) and returns each with a small integer id, role, text, CSS selector, and viewport coordinates.
By default it also draws numbered badges on the live page — call the base connector's
screenshot tool right after this to visually ground the ids, then reference them as
elementId in operagx_click / operagx_type_text / etc. Call operagx_clear_annotations when
done looking, so the badges don't linger in future screenshots.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab to scan. Defaults to the first open tab.
annotate (boolean, default true): draw numbered overlay badges.
visibleOnly (boolean, default true): skip elements outside the viewport or CSS-hidden.
limit (number, default 100, max 500): cap on elements returned, to avoid overwhelming context on dense pages.
Returns: { "count": number, // elements actually returned (<= limit) "totalFound": number, // elements matched before truncation "truncated": boolean, // true if totalFound > count "elements": [ { "id": number, // pass this as elementId to other tools "tag": string, // e.g. "input", "button", "a" "role": string | null, // ARIA role, if set "text": string, // visible text / placeholder / aria-label, truncated to 120 chars "selector": string, // CSS selector (fallback addressing) "rect": { "x": number, "y": number, "width": number, "height": number }, "center": { "x": number, "y": number }, "attributes": { [name: string]: string } // id/class/name/type/role/placeholder/aria-label/value/href } ] }
Examples:
Use when: "click the login button" -> map_elements first to find its id, then operagx_click with that elementId.
Use when: a page has more interactive elements than the default limit -> re-call with a higher limit, or narrow with visibleOnly=true (default) to only what's on-screen.
Don't use when: you already have a fresh element map from a moment ago and the page hasn't changed — re-resolve selectors instead of re-scanning.
Error Handling:
Returns "No open tabs found..." if the browser has no open tabs — open one first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum elements to return (default 100, max 500). | |
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| annotate | No | Draw numbered overlay badges on the live page for the next screenshot. | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| matchTitle | No | Pick the tab whose title contains this substring. | |
| visibleOnly | No | Skip elements outside the viewport or hidden via CSS display/visibility. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| elements | Yes | |
| truncated | Yes | |
| totalFound | Yes |
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.
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.
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.
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.
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.
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.
Sends a key or chord to the focused element or page, e.g. "Enter", "Escape", "Tab", "Control+A", "Control+Shift+ArrowLeft". If a target is given, it is clicked/focused first.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab to send the key to.
elementId / selector / x+y (all optional): if given, focus this element first; otherwise the key goes to whatever currently has focus.
key (string): Playwright key syntax, e.g. "Enter" or "Control+A".
Returns: { "ok": true }
Examples:
Use when: "press Enter to submit the search" -> press_key with key="Enter" (target optional if the search field is already focused from a previous type_text call).
Use when: "select all text in this field" -> press_key with the field's elementId and key="Control+A".
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Absolute viewport x in CSS pixels, if not using elementId/selector. | |
| y | No | Absolute viewport y in CSS pixels, if not using elementId/selector. | |
| key | Yes | Playwright key syntax, e.g. "Enter" or "Control+A". | |
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| selector | No | CSS selector, if not using elementId. | |
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| elementId | No | Id from the last operagx_map_elements call (preferred — most robust). | |
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes |
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.
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.
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.
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.
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.
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.
Scrolls the page with a real mouse-wheel event, or scrolls a specific element into view.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab.
elementId / selector (optional): if given, scrolls that element into view instead of wheel-scrolling the page.
deltaX / deltaY (number, default 0): wheel scroll amount in CSS pixels, used only when no elementId/selector is given.
Returns: Either { "ok": true, "scrolledTo": { "x": number, "y": number, "selector"?: string } } or { "ok": true, "delta": { "x": number, "y": number } }
Examples:
Use when: "scroll down to load more results" -> scroll with deltaY=800.
Use when: "scroll the footer link into view" -> scroll with that link's elementId.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| deltaX | No | ||
| deltaY | No | ||
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| selector | No | ||
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| elementId | No | ||
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| delta | No | |
| scrolledTo | No |
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.
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.
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.
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.
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.
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.
Chooses an option in a native dropdown by value, label, or index.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab.
selector (string): CSS selector for the element.
value / label / index: exactly one, identifying which option to choose.
Returns: { "ok": true, "selected": string[] } // the value(s) selected, per the DOM API
Examples:
Use when: "choose 'Option 2' from the dropdown" -> select_option with the select's selector and label="Option 2".
Error Handling:
Playwright throws if the selector doesn't resolve to a , or the option doesn't exist — the error message names the selector and requested value.
| Name | Required | Description | Default |
|---|---|---|---|
| index | No | Select the option at this zero-based index. | |
| label | No | Select the option with this visible label. | |
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| value | No | Select the option with this value attribute. | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| selector | Yes | CSS selector for the <select> element. | |
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| selected | Yes |
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.
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.
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.
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.
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.
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.
Focuses an element (by clicking it) and types text using real per-character key events (CDP Input.dispatchKeyEvent), so JS keydown/input listeners, IME composition, and masked inputs behave like real typing rather than a value assignment.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab to type into.
elementId / selector / x+y: exactly one, same as operagx_click — identifies the field.
text (string): the text to type.
clearFirst (boolean, default true): select-all + Backspace before typing, to replace any existing value instead of appending.
delayMs (number, default 20): delay between keystrokes; raise it for sites that debounce input handling.
Returns: { "ok": true, "typedInto": { "x": number, "y": number, "selector"?: string } }
Examples:
Use when: "enter 'tomsmith' in the username field" -> map_elements for its elementId, then type_text with text="tomsmith".
Don't use when: filling several fields at once — use operagx_fill_form instead, it's one tool call for the whole form and can submit at the end.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Absolute viewport x in CSS pixels, if not using elementId/selector. | |
| y | No | Absolute viewport y in CSS pixels, if not using elementId/selector. | |
| text | Yes | The text to type. | |
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| delayMs | No | Delay between keystrokes in ms, for sites that debounce input. | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| selector | No | CSS selector, if not using elementId. | |
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| elementId | No | Id from the last operagx_map_elements call (preferred — most robust). | |
| clearFirst | No | Select-all + Backspace before typing. | |
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| typedInto | Yes |
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.
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.
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.
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.
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.
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.
Waits until a selector reaches a given state, or times out.
Args:
tabId / tabIndex / matchUrl / matchTitle (optional): which tab.
selector (string): CSS selector to wait for.
state ('attached' | 'visible' | 'hidden' | 'detached', default 'visible').
timeoutMs (number, default 10000).
Returns: { "ok": true }
Examples:
Use when: "wait for the spinner to disappear before continuing" -> wait_for with the spinner's selector and state="hidden".
Error Handling:
Throws a timeout error naming the selector and state if it isn't reached in time.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | visible | |
| tabId | No | Tab id from operagx_list_tabs. Omit to use the first open tab. | |
| matchUrl | No | Pick the tab whose URL contains this substring. | |
| selector | Yes | ||
| tabIndex | No | Zero-based tab index, alternative to tabId. | |
| timeoutMs | No | ||
| matchTitle | No | Pick the tab whose title contains this substring. |
| Name | Required | Description |
|---|---|---|
| ok | Yes |
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.
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.
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.
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.
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.
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.
Each tool targets a distinct user interaction: typing, clicking, hovering, key presses, form filling, option selection, drag-and-drop, scrolling, waiting, and element mapping. Even the overlapping type_text and fill_form are clearly differentiated by scope (single field vs. multi-field with submit).
All tools share the 'operagx_' prefix and use clear snake_case verb-based names (type_text, list_tabs, clear_annotations, drag_and_drop). Single-word verbs like 'click' and 'scroll' are still consistent with the action-oriented pattern and do not cause confusion.
12 tools is a well-scoped set for a browser interaction extension. Each tool covers a distinct, commonly needed automation primitive without redundancy, fitting comfortably within the ideal 3-15 tool range.
The interaction surface is strong: click, type, hover, key press, form fill, select, drag-and-drop, scroll, wait, and element mapping. Minor gaps exist like file upload or iframe switching, but these are likely left to the base connector, so the extension's purpose is well covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Automate cloud Chrome—navigate, click, type, screenshot, run code, record screen video
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Zindaar/operagx-connector-plus'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
