nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Evaluate JavaScript

evaluate_script

Run custom JavaScript in the page and get a JSON result—use it to read computed styles, call page APIs, or extract structured data in one round trip.

Instructions

Run JavaScript inside the page and get the result back as JSON.

The escape hatch for anything the other tools do not cover: reading computed styles, calling a page's own JS API, or extracting structured data in a single round trip instead of a dozen snapshot-and-click cycles.

Without args the function runs at page level in the main world. With args, the given uids become real element references, which is how you operate on one specific element from a snapshot.

Return values must be JSON-serialisable — DOM nodes, functions and circular structures are not, so map them to plain values inside the function. A script that throws comes back as a failed call carrying the JavaScript error, not as a result you have to inspect for the word "Error".

Pass script_path to run a function kept in a .js file, and file_path to write the result to disk instead of into the conversation.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`args`	No	Element uids from the most recent take_snapshot, resolved to live DOM nodes and passed as the function's arguments. The first uid is also bound as `this`. Omit for page-level scripts.
`frame`	No	Run inside one of the page's frames instead of the main document: an index or frame id from list_frames. Runs in an isolated world, which shares the frame's DOM but not its own JavaScript variables, so use it to read and drive the DOM rather than to call the page's own functions. Ignored when `args` is given, since a uid already carries its frame.
`browser`	No	Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.	default
`function`	No	A JavaScript function expression, e.g. "() => document.title" or "(el) => el.innerText". It is invoked immediately and its return value is JSON-serialised back to you. Async functions are awaited, so "async () => (await fetch('/api/x')).json()" works. Return a value — console.log output is not captured. Leave empty when using script_path.
`file_path`	No	Write the JSON result to this local path instead of returning it — for extractions too large to put in the conversation.
`script_path`	No	Read the function from this local .js file instead of the `function` parameter. Use it for anything long or quote-heavy, where escaping the script into a JSON string is where the mistakes happen.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv2.5.0Sep 25, 2026

addedInput schema / properties / browser

Added value: +{
+  "default": "default",
+  "description": "Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.",
+  "type": "string"
+}

addedInput schema / properties / file_path

Added value: +{
+  "default": "",
+  "description": "Write the JSON result to this local path instead of returning it — for extractions too large to put in the conversation.",
+  "title": "File Path",
+  "type": "string"
+}

addedInput schema / properties / frame

Added value: +{
+  "default": "",
+  "description": "Run inside one of the page's frames instead of the main document: an index or frame id from list_frames. Runs in an isolated world, which shares the frame's DOM but not its own JavaScript variables, so use it to read and drive the DOM rather than to call the page's own functions. Ignored when `args` is given, since a uid already carries its frame.",
+  "title": "Frame",
+  "type": "string"
+}

addedInput schema / properties / function / default
```
Added value: +""
```

changedInput schema / properties / function / description

Previous value: -"A JavaScript function expression, e.g. \"() => document.title\" or \"(el) => el.innerText\". It is invoked immediately and its return value is JSON-serialised back to you. Async functions are awaited, so \"async () => (await fetch('/api/x')).json()\" works. Return a value — console.log output is not captured."New value: +"A JavaScript function expression, e.g. \"() => document.title\" or \"(el) => el.innerText\". It is invoked immediately and its return value is JSON-serialised back to you. Async functions are awaited, so \"async () => (await fetch('/api/x')).json()\" works. Return a value — console.log output is not captured. Leave empty when using script_path."

addedInput schema / properties / script_path

Added value: +{
+  "default": "",
+  "description": "Read the function from this local .js file instead of the `function` parameter. Use it for anything long or quote-heavy, where escaping the script into a JSON string is where the mistakes happen.",
+  "title": "Script Path",
+  "type": "string"
+}

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

First observedv1.7.2Aug 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

It reveals behavior well beyond the annotations: main-world vs isolated-world execution, uid-to-live-element binding, JSON-serialisability constraints, thrown-error handling, and the rationale for script_path. The readOnlyHint=false and idempotentHint=false annotations are consistent with running arbitrary page JavaScript, and the description adds the operational detail an agent needs.

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 dense but every sentence earns its place: core definition, usage rationale, argument modes, return/error behavior, and file-based alternatives. It is front-loaded with the one-sentence definition and uses short paragraphs that are easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity, arbitrary-JavaScript tool with six parameters and rich schema descriptions, this description covers the execution environment, argument passing, result serialization, failure semantics, and file-based workflow. The existing annotations already carry the read-only/destructive hints, so nothing an agent needs to invoke the tool correctly is missing.

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 100%, and the schema already documents each parameter well. The description still adds useful meaning: the main-world page-level mode without args, the element-reference mode with args, and the practical constraint that DOM nodes, functions, and circular structures must be mapped to plain values. Some of the script_path/file_path guidance partly duplicates the schema, so the added value is real but not maximal.

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 opening sentence states the exact action ('Run JavaScript inside the page') and result ('get the result back as JSON') with a specific verb and resource. The 'escape hatch' framing with concrete examples distinguishes it from the many action-oriented sibling tools such as click, fill, and take_snapshot.

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

Usage Guidelines4/5

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

The description gives explicit conditions for use: when the other tools do not cover a need, and for computed styles, calling a page's own JS API, or single-round-trip data extraction. It also routes between inline functions, script_path, and file_path. It does not name a specific sibling to prefer in a particular case, so the guidance is clear but not fully exclusionary.

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

Deploy Server