nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Take page snapshot

take_snapshot

Read-only

Read a page as compact, searchable text with stable element IDs, enabling reliable clicks, fills, and other actions. Use it to inspect page structure and obtain valid IDs for interaction.

Instructions

Read the page as compact text, with a uid for every element.

This is the primary way to see a page, and the source of the uids that click, fill, hover, drag and upload_file all take. Prefer it over take_screenshot for anything but a genuine visual check: it is searchable, far smaller, and it is what makes interaction possible at all.

The output is the accessibility tree — roles, names, values and states, indented by nesting — with Chrome-internal and purely presentational nodes filtered out unless verbose is set.

A URL on the same origin as the page is printed relative to it — the root node carries the absolute one, so nothing is lost and a link-dense page costs noticeably less to read.

uids stay stable across snapshots for elements that did not change, but any page change can invalidate them. Whenever a tool reports "unknown uid", take a fresh snapshot and use the new uid. Output is capped at 200 000 characters.

Frames are included and marked, so an element inside an iframe gets a uid like any other and click, fill and evaluate_script work on it unchanged.

For plain page text without uids, get_page_content is cheaper; to find elements by CSS selector, use query_selector.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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
`verbose`	No	Return the complete accessibility tree, including nodes normally filtered out as noise and containers that are otherwise collapsed. Much larger — use it only when an element you need is missing from the default output.
`file_path`	No	Write the snapshot to this local path instead of returning it — useful for very large pages you intend to search rather than read in full.
`include_frames`	No	Also read the page's iframes and splice each one in under the element that hosts it. On by default, because Chrome's accessibility tree stops at a frame boundary and anything inside an iframe would otherwise be invisible. Set false on a page with many frames to keep the output small.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 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 / include_frames

Added value: +{
+  "default": true,
+  "description": "Also read the page's iframes and splice each one in under the element that hosts it. On by default, because Chrome's accessibility tree stops at a frame boundary and anything inside an iframe would otherwise be invisible. Set false on a page with many frames to keep the output small.",
+  "title": "Include Frames",
+  "type": "boolean"
+}

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?

Beyond the readOnly/destructive annotations, the description discloses the output shape (accessibility tree with roles, names, values, states), filtering behavior, 200,000-character cap, relative URL printing, frame inclusion, and uid invalidation on page changes. No statement contradicts the annotations.

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 long but information-dense: definition, routing guidance, output format, uid lifecycle, frame behavior, and alternatives each earn their place. It front-loads the core purpose and avoids repeating schema boilerplate.

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?

With full parameter schemas and an output schema present, the description still adds the operational context an agent needs: size cap, uid stability, frame handling, relative URLs, and recovery instructions. Nothing critical for calling the tool correctly is missing.

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?

All four parameters already have detailed schema descriptions at 100% coverage, so the baseline is 3. The description reinforces the meaning of 'verbose' and frame inclusion, but it does not meaningfully add semantic detail about 'browser' or 'file_path' beyond what the schema already provides.

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 opens with a specific operation—'Read the page as compact text, with a uid for every element'—and clearly identifies the tool as the primary snapshot mechanism. It also distinguishes itself from take_screenshot, get_page_content, and query_selector, so an agent can select it without ambiguity.

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?

It gives direct routing rules: prefer this over take_screenshot except for a genuine visual check, use get_page_content for plain text without uids, and use query_selector for CSS-selector lookup. It also signals when to use verbose mode and when a fresh snapshot is needed after a stale uid.

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

Deploy Server