real-browser-mcp-server

see_page

Capture a page snapshot with screenshot, text, element map, and iframe list in one call; then run click, type, scroll, and extract steps without recapturing.

Instructions

Capture a snapshot of the current page. Returns a screenshot image together with optional full-page text, an interactive element map (buttons, links, inputs with position and selector), and an iframe inventory — all in a single call.

Workflow: Call once with fullPage:true and annotate:true. From that snapshot, run all planned actions (click, type, scroll, wait, extract) as a steps array without re-capturing the page. Call see_page again only when the page genuinely changes (new navigation, modal, or dynamic content load).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "see_page"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No	File path to also save the screenshot image
`async`	No	When steps are present: run as a background job — returns a jobId immediately instead of blocking; poll async_job for the result.
`steps`	No	Actions to run sequentially right after capturing the page, without re-capturing between steps. Supported: click, type, press_key, scroll, wait, extract, see, drag, hover, double_click, triple_click, idle.
`format`	No		jpeg
`quality`	No	JPEG quality 0-100
`annotate`	No	Draw numbered bounding boxes over interactive elements for precise targeting
`fullPage`	No	Capture the full scrollable page instead of only the visible viewport
`autoHover`	No	Hover over navigation menus before capturing to reveal dropdowns
`maxElements`	No	Maximum number of interactive elements to map
`scanIframes`	No	List embedded iframes with their index and URL
`stopOnError`	No	Stop step execution on first failure
`captureAfter`	No	Take a screenshot after the steps array completes
`saveBaseline`	No	Save current screenshot as visual baseline for later comparison
`captureBefore`	No	Take a screenshot before running the steps array
`includeDomText`	No	Include the full DOM text content
`watchMutations`	No	Report DOM mutations (popups, alerts) since the last capture
`compareBaseline`	No	Compare current screenshot against saved baseline; returns diffPercent
`includeElements`	No	Include the interactive element map in the response
`includePageText`	No	Include cleaned page text

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv3.3.14Oct 23, 2026

addedInput schema / properties / async

Added value: +{
+  "default": false,
+  "description": "When steps are present: run as a background job — returns a jobId immediately instead of blocking; poll async_job for the result.",
+  "type": "boolean"
+}

addedInput schema / properties / maxElements / maximum
```
Added value: +200
```
addedInput schema / properties / steps / maxItems
```
Added value: +100
```

Changed2 schema fields changedv3.3.10Oct 21, 2026

addedInput schema / properties / compareBaseline

Added value: +{
+  "default": false,
+  "description": "Compare current screenshot against saved baseline; returns diffPercent",
+  "type": "boolean"
+}

addedInput schema / properties / saveBaseline

Added value: +{
+  "default": false,
+  "description": "Save current screenshot as visual baseline for later comparison",
+  "type": "boolean"
+}

First observedv3.2.13Sep 5, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the return payload shape and the important non-obvious behavior that steps execute without intermediate re-capture. It leaves unmentioned the baseline save/compare, mutation watching, and the async job behavior, all of which remain schema-only.

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 short paragraphs; the first states what the tool is and returns, the second is a labeled workflow rule. Every sentence carries decision-relevant information and the recommended invocation flags are front-loaded.

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?

For a 19-parameter, zero-required browser-capture tool with no annotations and no output schema, the description covers the core loop an agent needs (capture once, batch actions, recapture only on real change). It omits any mention of the async job path, baseline comparison, or mutation watching, which are secondary but not negligible given async changes the call semantics entirely.

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 95%, so baseline is 3; the description earns above baseline by explaining the relationship the schema cannot — that 'steps' runs sequentially after the capture with no re-capture between steps, and that fullPage/annotate are the recommended starting flags. It does not touch the other 17 parameters, but the schema documents them fully.

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

Purpose4/5

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

States a specific verb and resource ('Capture a snapshot of the current page') and enumerates precisely what the snapshot contains: screenshot image, optional page text, interactive element map, iframe inventory. That composite output implicitly differentiates it from single-purpose siblings like get_content or click, though no sibling is named explicitly.

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?

Explicitly prescribes a call pattern ('Call once with fullPage:true and annotate:true'), states the alternative workflow (run all planned actions as a steps array without re-capturing), and gives the exact condition for a repeat call ('only when the page genuinely changes — new navigation, modal, or dynamic content load'). This is as close to a rulebook as a description gets.

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