real-browser-mcp-server

execute_js

Run custom JavaScript in a browser page or iframe to capture return values, and replay HTTP requests using the page session for authenticated fetches.

Instructions

Execute custom JavaScript in the page context with async support, return value capture, and iframe targeting. Also supports action="fetch" to replay HTTP requests with the page session (cookies/auth inherited, 30s timeout, structured status/headers/body output).

Input Schema

Name	Required	Description	Default
`url`	No	URL for fetch action
`body`	No	Body for fetch action (POST/PUT)
`code`	No	JavaScript code to execute in the page context (required unless action="fetch")
`async`	No	Run as a background job: returns a jobId immediately instead of blocking; poll async_job for the result. Inside the job the code is wrapped in an async function, so top-level await works.
`action`	No	execute: run JS code; fetch: replay an HTTP request with page session	execute
`iframe`	No	Execute inside a specific iframe (0 = main frame, 1+ = iframe by index)
`method`	No	HTTP method for fetch action	GET
`headers`	No	Headers for fetch action
`timeout`	No
`returnValue`	No	Return the result of the expression
`waitForIframe`	No	Wait for the iframe to finish loading before executing
`iframeSelector`	No	Execute inside iframe matched by CSS selector

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv3.3.14Oct 23, 2026

changedInput schema / properties / async / description

Previous value: -"Wrap code in an async function"New value: +"Run as a background job: returns a jobId immediately instead of blocking; poll async_job for the result. Inside the job the code is wrapped in an async function, so top-level await works."

addedInput schema / properties / code / maxLength
```
Added value: +200000
```

Changed7 schema fields changedv3.3.10Oct 21, 2026

addedInput schema / properties / action

Added value: +{
+  "default": "execute",
+  "description": "execute: run JS code; fetch: replay an HTTP request with page session",
+  "enum": [
+    "execute",
+    "fetch"
+  ],
+  "type": "string"
+}

addedInput schema / properties / body

Added value: +{
+  "description": "Body for fetch action (POST/PUT)",
+  "type": "string"
+}

changedInput schema / properties / code / description

Previous value: -"JavaScript code to execute in the page context"New value: +"JavaScript code to execute in the page context (required unless action=\"fetch\")"

addedInput schema / properties / headers

Added value: +{
+  "description": "Headers for fetch action",
+  "type": "object"
+}

addedInput schema / properties / method

Added value: +{
+  "default": "GET",
+  "description": "HTTP method for fetch action",
+  "type": "string"
+}

addedInput schema / properties / url

Added value: +{
+  "description": "URL for fetch action",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "code"
-]
```

First observedv3.2.13Sep 5, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does add real behavioral context: cookies/auth are inherited from the page session, fetch has a 30s timeout, and output is structured as status/headers/body. It omits the elevated trust level of arbitrary page-context code execution and what happens on script errors, but the fetch-mode semantics are unusually well disclosed.

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

Conciseness4/5

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

Two dense sentences with the primary capability front-loaded and the secondary mode clearly signposted by 'Also supports'. The middle clause is a compressed parameter summary that reads slightly like a teaser list, but nothing is wasted.

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 12-parameter, no-annotation, no-output-schema tool this covers the two modes and the fetch return shape adequately. Gaps remain around what execute mode returns, error/timeout behavior beyond fetch, and the async job hand-off, which is left entirely to the schema.

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 92%, so parameter documentation is already largely handled and the baseline is 3. The description mirrors the schema's framing (async support, return value capture, iframe targeting, fetch action) rather than adding format or behavioral detail beyond it, and says nothing about the 200k code length cap or the timeout/returnValue interactions.

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+resource combination ('Execute custom JavaScript in the page context') and enumerates the three capabilities (async, return value, iframe targeting) plus a second mode ('action="fetch"' for HTTP replay). Among siblings it is clearly the only arbitrary-code tool, though it doesn't explicitly name which sibling to use instead for read/extract tasks.

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

Usage Guidelines3/5

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

No explicit when-to-use / when-not-to guidance or named alternatives; the async path's hand-off to async_job polling appears only in the schema, not the description. Usage is implied by the capability list, so an agent must infer that this is the fallback when structured tools like get_content or extract_data can't do the job.

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

execute_js

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools