nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Capture response bodies to disk

capture_bodies

Capture matching network response bodies to disk the moment they arrive, before Chrome discards them. Preserves large or post-navigation responses for later retrieval, with metadata in capture.jsonl.

Instructions

Save every matching response body to disk the moment it arrives, in the background.

get_network_request asks Chrome for a body only when you ask — by then it is often gone: Chrome drops bodies over ~10 MB at once, and a navigation to another site drops the rest. This takes each body while the response is still paused, before the page even sees it, and writes it to a file.

Covers the whole browser until stopped: every tab, including ones the page opens itself, plus dedicated workers and service workers. Each body is its own file; capture.jsonl beside them records URL, method, POST data, status and headers per file. list_network_requests marks captured requests "saved", and get_network_request falls back to the file.

Not captured: responses from Chrome's cache (they never touch the network — reload with ignore_cache), redirects, and event streams inside workers. Event streams on a page are written as they arrive; every other matching response reaches the page only once complete, so keep the pattern off long-running downloads.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`action`	No	"start" begins capturing in the background, "status" reports progress while it runs, "stop" ends it and reports what was saved.	start
`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
`out_dir`	No	Folder to write into, created if missing. Empty uses ~/.nodriver-mcp/captures/<timestamp>.
`max_body_mb`	No	Skip a response whose Content-Length announces more than this many MB. A captured body is held in memory whole on its way to disk.
`url_pattern`	No	Which responses to keep, matched against the full URL — required for start. "" matches any run of characters and "?" exactly one, as in Chrome's own interception patterns: "/api/", "graphql". A pattern without "" matches anywhere in the URL. "*" keeps everything.
`resource_types`	No	Only these resource types, e.g. ["XHR", "Fetch"] for a page's own API calls. Omit for all.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.5.0Sep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes far beyond the sparse annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false). It discloses background execution, browser-wide coverage including workers, the capture.jsonl sidecar, interaction with list_network_requests and get_network_request, memory-in-whole behavior, and exact exclusions. No contradiction with 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 most important action and scope appear in the first sentence. The remaining paragraphs add necessary behavioral context, exclusions, and integration notes without filler. Every sentence earns its place, and the structure is logical: what, why, scope, exclusions.

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 complex background-capture tool with six parameters and output schema, the description covers the full behavioral contract: what is captured, what is not, how the files are organized, how it interacts with sibling tools, and a memory warning via the max_body_mb parameter. Nothing essential 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add new parameter-level meaning beyond the schema, but it does provide behavioral context that helps an agent understand the lifecycle (start/status/stop) and the inter-tool effects of captured bodies. This keeps it at a solid 3.

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?

Opens with a specific verb-resource pair: "Save every matching response body to disk the moment it arrives, in the background." It clearly differentiates from get_network_request by explaining that the sibling asks Chrome lazily and often misses bodies, whereas this tool captures them while the response is still paused.

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?

Explicitly contrasts with get_network_request, explains when this tool is necessary (bodies are often gone by request time), and lists concrete exclusions: cache responses, redirects, and event streams inside workers. It also gives actionable advice such as using ignore_cache and keeping patterns off long-running downloads.

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

Deploy Server