nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Get page content

get_page_content

Read-only

Extract visible text or full HTML from a page directly, optionally writing to a file. Read content without building accessibility trees or dealing with selectors.

Instructions

Get the page's visible text, or its full HTML.

The cheapest way to read a page when you only need content and not the uids take_snapshot provides: no accessibility tree is built, and the text form carries no markup overhead.

Returns the DOM as it stands right now, so on pages that render asynchronously call wait_for or wait_for_selector first.

Use take_snapshot when you intend to interact with elements, and query_selector when you want specific elements rather than the whole page.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`frame`	No	Read inside one of the page's frames instead of the main document: an index or frame id from list_frames. Chrome's DOM queries never cross a frame boundary, so anything inside an iframe is unreachable without this. The frame is read through an isolated world, which shares the DOM but not the page's own JavaScript variables. Empty string reads the main document.
`format`	No	"text" returns document.body.innerText — visible text without markup, which is what you want for reading. "html" returns the full outerHTML including scripts and attributes, needed when you care about markup, data- attributes or hidden field values.	text
`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
`file_path`	No	Write the content to this local path instead of returning it — the way to capture a large page without flooding the conversation.
`max_chars`	No	Truncate the output at this many characters. 0 means no limit, which is risky on large pages — especially with format="html".

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 / frame

Added value: +{
+  "default": "",
+  "description": "Read inside one of the page's frames instead of the main document: an index or frame id from list_frames. Chrome's DOM queries never cross a frame boundary, so anything inside an iframe is unreachable without this. The frame is read through an isolated world, which shares the DOM but not the page's own JavaScript variables. Empty string reads the main document.",
+  "title": "Frame",
+  "type": "string"
+}

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 readOnlyHint/destructiveHint annotations, the description discloses the live-DOM semantics ('Returns the DOM as it stands right now') and the resulting async-rendering caveat, plus performance traits (no accessibility tree built, no markup overhead). These are genuine behavioral facts an agent needs that the annotations do not convey, and there is no contradiction with the readOnly hint.

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?

Four sentences, each earning its place: purpose, cost/performance positioning, behavioral caveat, and sibling routing. The core purpose is front-loaded in the first sentence, and there is zero filler or repetition of schema content.

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 5-parameter tool with 100% schema coverage, an output schema, and safety annotations, the description covers everything an agent needs for correct selection and invocation: what it returns, when to prefer alternatives, and the key timing caveat. The remaining parameter details are fully handled by the input 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 description coverage is 100%, so the baseline 3 applies; the schema already richly documents format (innerText vs outerHTML), frame isolation, file_path for large pages, and max_chars truncation. The description adds marginal semantic color ('text form carries no markup overhead') but does not meaningfully compensate beyond the schema's existing coverage.

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 first sentence states a specific verb and resource ('Get the page's visible text, or its full HTML') and the description repeatedly differentiates from siblings: take_snapshot (provides uids, builds accessibility tree) and query_selector (specific elements). An agent can distinguish this tool from its nearest alternatives without opening their schemas.

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?

The description gives explicit when/when-not guidance with named alternatives: use this as 'the cheapest way to read a page when you only need content,' 'Use take_snapshot when you intend to interact with elements,' and 'query_selector when you want specific elements.' It also tells the agent to call wait_for or wait_for_selector first on asynchronously rendering pages. Nothing is left to inference.

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

Deploy Server