OpenChrome

interact

Locate and operate on webpage elements using natural language descriptions, then wait for the page to settle and return the updated state. Use for single-element actions like clicking, hovering, or double-clicking.

Instructions

Find element by natural language; click/hover/double_click it; wait for DOM settle; return state.

When to use: One described element action, with coordinate fallback for Shadow DOM/canvas/iframes. When NOT to use: Use act for multi-step flows; computer for general coordinate clicks.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ref`	No	Snapshot ref ID (from read_page refs map). When provided, skips AX re-resolution and clicks the element directly via its cached backendDOMNodeId.
`mode`	No	Dispatch mode. "ref" resolves by query, "coordinate" sends a pixel event, and "perception" executes one caller-selected snapshot element after provenance validation.	ref
`query`	No	Element to act on (natural language). Required when mode is "ref" (default).
`tabId`	No	Tab ID to execute on
`value`	No	Text to type when action is type. Supports vault://name in pilot mode.
`action`	No	Action to perform. Default: click. Use type with value to enter text.
`intent`	No	Optional short label (≤120 chars) describing the user-facing goal of this action, e.g. "submit login form". Recorded in the task journal for observability.
`laneId`	No	Task-scoped browser lane id; validates tabId or defaults to the lane current target.
`taskId`	No	Task id when using a task-scoped browser lane.
`verify`	No	Verify mode. boolean is legacy: true→"screenshot", false→"none". String enum returns a compact diff signal (AX-hash delta + pHash, ≤4KB).
`waitAfter`	No	DOM settle wait in ms. Default: 500
`waitForMs`	No	Poll timeout for element in ms. Max: 30000
`coordinate`	No	Pixel coordinates for coordinate mode. Required when mode is "coordinate".
`perception`	No	Caller-selected visual target for perception mode. The snapshot is validated and never echoed in the response.
`pollInterval`	No	Poll interval in ms. Default: 200
`returnFormat`	No	Response content. Default: both
`locatorFallback`	No	Opt-in AI locator fallback extension point. Disabled by default; when enabled, provider candidates are validated before any action.
`capture_artifact`	No	When true, stage a replay artifact step for oc_skill_record after a successful click. Default false is a strict no-op.
`returnAfterState`	No	Optional chaining hint. When "ax" or "dom", the response includes a page snapshot of that mode captured after the post-action wait, removing the need for a follow-up read_page call. Default: "none".

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.13.0Sep 9, 2026

changedInput schema / properties / mode / description

Previous value: -"Dispatch mode. \"ref\" (default) resolves the element by query; \"coordinate\" sends a CDP mouse event directly to pixel coordinates."New value: +"Dispatch mode. \"ref\" resolves by query, \"coordinate\" sends a pixel event, and \"perception\" executes one caller-selected snapshot element after provenance validation."

changedInput schema / properties / mode / enum

Previous value: -[
-  "ref",
-  "coordinate"
-]New value: +[
+  "ref",
+  "coordinate",
+  "perception"
+]

addedInput schema / properties / perception

Added value: +{
+  "description": "Caller-selected visual target for perception mode. The snapshot is validated and never echoed in the response.",
+  "properties": {
+    "elementId": {
+      "description": "Exact snapshot-local element ID selected by the caller.",
+      "maxLength": 160,
+      "minLength": 1,
+      "type": "string"
+    },
+    "snapshot": {
+      "description": "Provider-neutral viewport-mode PerceptionSnapshot returned by vision_find format=\"snapshot\".",
+      "type": "object"
+    }
+  },
+  "required": [
+    "snapshot",
+    "elementId"
+  ],
+  "type": "object"
+}

First observedv1.12.8Jun 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The description discloses the key behavioral steps (find, act, wait for DOM settle, return state) and the annotations confirm it is not read-only. It does not explicitly mention potential side effects like navigation or state mutation beyond the action itself, but the interaction nature is clear and the 'wait for DOM settle' detail adds transparency.

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

Conciseness5/5

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

The description is concise, using a single-purpose sentence followed by clear usage boundaries. The structuring into 'When to use' and 'When NOT to use' makes it scannable and efficient, with no redundant or filler content.

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 tool's complexity (19 parameters, nested objects) and the absence of an output schema, the description provides adequate context by stating the return of state and positioning it against sibling tools. It does not enumerate all parameters, but that is appropriately delegated to the schema; the description could be more explicit about what 'state' includes, but it is sufficient for an agent to decide when to use it.

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

Parameters3/5

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

The description itself contributes minimal parameter-specific meaning; it only hints at the mode distinction via 'natural language' and 'coordinate fallback'. Since the schema already provides 100% coverage with detailed descriptions, the baseline of 3 applies, and the description does not elevate it further.

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 primary function: find element by natural language, perform a click/hover/double_click, wait for DOM settle, and return state. The 'When to use' section reinforces the intended use case of a single described element action, making the purpose unambiguous.

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

Usage Guidelines5/5

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

Explicit 'When to use' and 'When NOT to use' sections provide direct guidance: use for one described element action with coordinate fallback for Shadow DOM/canvas/iframes, and avoid for multi-step flows (use act) or general coordinate clicks (use computer). This leaves no room for misinterpretation.

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

Deploy Server

interact

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools