real-browser-mcp-server

click

Triggers or drags page elements by CSS selector or annotation ID, with hover, iframe targeting, video-player control, and retry fallback handling.

Instructions

Click or drag a page element by CSS selector or annotation ID. Supports drag-and-drop / slider manipulation via dragTo, iframe context, hover before click, video player API, and automatic retry with fallback selectors.

Input Schema

Name	Required	Description
`delay`	No
`aiHeal`	No	Try alternative selector if primary fails
`dragTo`	No	Drag and drop the source element to target selector or coordinates with biological friction and overshoot correction
`iframe`	No	Target a specific iframe by index (use media_extractor list_iframes to get index)
`retries`	No	Retry count on failure
`timeout`	No	Max time to wait for element to appear (ms)
`selector`	No	CSS selector for the element to click
`hoverOnly`	No	Hover only, do not click (to reveal hidden controls)
`humanLike`	No	Smooth cursor movement before click
`clickCount`	No
`forceClick`	No	Click via JavaScript even if element is not visible
`hoverFirst`	No	Hover over element before clicking (for dynamic controls)
`waitForPlay`	No	Wait until the video starts playing after click
`annotationId`	No	Annotation number from see_page(annotate:true) — use instead of selector
`usePlayerAPI`	No	Control video player via its JavaScript API instead of DOM click
`hoverDuration`	No	Wait time after hover before clicking (ms)
`playerTimeout`	No	Max time to wait for video playback to start (ms)
`iframeSelector`	No	Target a specific iframe by CSS selector
`scrollIntoView`	No	Scroll element into view before clicking
`autoDetectPlayer`	No	Detect and target embedded video player iframes automatically
`autoAcceptDialogs`	No	Auto-dismiss browser dialogs (alerts, confirms)

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv3.3.14Oct 23, 2026
- addedInput schema / properties / delay / maximum
```
Added value: +1000
```
- addedInput schema / properties / playerTimeout / maximum
```
Added value: +30000
```
- addedInput schema / properties / retries / maximum
```
Added value: +5
```
- addedInput schema / properties / timeout / maximum
```
Added value: +60000
```
First observedv3.2.13Sep 5, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It discloses several capabilities (drag-and-drop, iframe context, hover, video player API, automatic retry with fallback selectors), but it does not mention side effects (navigation, form submission), permissions, or failure behavior beyond retry. This is useful but incomplete for a potentially destructive action like clicking.

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?

Two sentences, front-loaded with the primary action and then a compact list of supported behaviors. No filler or redundancy; every sentence earns its place.

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 a rich schema (21 params, 90% coverage, nested object) and no output schema, the description covers the main capabilities adequately. It does not explain parameter interactions or the anyOf requirement, but the schema handles those details, so the description is nearly complete for its complementary role.

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

Parameters3/5

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

Schema description coverage is 90%, so the schema already documents nearly all parameters in detail. The description only references dragTo, iframe, hover, and retry at a high level, adding no new semantic detail beyond what the schema provides. Baseline 3 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 a specific verb and resource: 'Click or drag a page element by CSS selector or annotation ID.' It is immediately clear what the tool does and how the target is specified, distinguishing it from siblings like type or press_key without needing to enumerate them.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives (e.g., type, press_key, execute_js) or when not to use it. The only implicit hint is 'use instead of selector' for annotationId, which is parameter-level, not tool-level.

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

click

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools