nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Query CSS selector

query_selector

Read-only

Find elements by CSS selector and return tag, text, href, id, and class. Pull repeated structures such as search results or table rows without a full snapshot.

Instructions

Find elements by CSS selector; list their tag, text, href, id and class.

The efficient way to pull a repeated structure off a page — search results, product tiles, table rows — without paying for a full snapshot.

Returns a compact listing only. It yields no uids, so it cannot drive clicks: take a snapshot when you need to interact, or operate on the elements directly via evaluate_script.

Element text is truncated to 200 characters.

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.
`limit`	No	Maximum number of matching elements to return.
`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
`selector`	Yes	A CSS selector, e.g. "a.result", "#nav li", "input[type=file]". Standard querySelectorAll syntax — no jQuery extensions such as :contains().

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 annotations (readOnlyHint=true, destructiveHint=false), the description adds significant behavioral detail: compact listing only, no uids, inability to drive clicks, 200-character text truncation, and frame-isolated-world semantics. Nothing 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?

Four short, information-dense sentences, each earning its place: core function, use case, limitation with alternatives, and truncation behavior. The most decision-relevant constraints are front-loaded.

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?

Given the output schema exists and the input schema is fully described, the prose covers all necessary decision factors: when to use, what it returns, what it cannot do, and a critical output limitation. An agent has enough to select and invoke this tool correctly.

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 is 3. The schema already provides strong parameter descriptions, including selector syntax limitations, frame isolation, browser naming, and limit semantics. The tool description itself does not add further parameter-level detail.

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 states a specific verb and resource: 'Find elements by CSS selector; list their tag, text, href, id and class.' It clearly distinguishes the tool from snapshot-based alternatives by emphasizing compact output, no uids, and repeated-structure extraction.

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 explicitly explains when to use this tool ('efficient way to pull a repeated structure off a page... without paying for a full snapshot') and when not to ('It yields no uids, so it cannot drive clicks'), with concrete alternatives: take_snapshot or evaluate_script. This is exemplary usage guidance.

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

Deploy Server