Skip to main content
Glama
andresolbach

nodriver-mcp-server

by andresolbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get network request

get_network_request
Read-only

Retrieve a captured network request's details—URL, method, resource type, and request/response bodies—to read the JSON data a page already fetched via its own API calls instead of scraping rendered DOM.

Instructions

Inspect one network request: URL, method, resource type and both bodies.

Often the fastest way to get structured data out of a site: find the page's own API call with list_network_requests, then read the JSON it already received here, instead of scraping the rendered DOM.

Inline bodies are truncated at 5000 characters, so pass a file path for anything larger. Response bodies are only available while Chrome still holds them in its buffer — for a long-finished request the entry may still be listed while its body is already gone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reqidNoRequest id, as shown in square brackets by list_network_requests. Omit to get the most recent request.
browserNoWhich 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
request_file_pathNoWrite the request body (POST data) to this local file path instead of including it in the response.
response_file_pathNoWrite the response body to this local file path instead of including it. Use this for binary responses (images, PDFs, archives) — they are base64-decoded on the way out.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.0
    • 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"
+}
  2. First observedv1.7.2

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds critical behavioral details beyond annotations: inline bodies are truncated at 5000 characters, and response bodies are only available while Chrome holds them in its buffer. These are non-obvious constraints an agent must know to call the tool correctly.

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?

Three tightly written paragraphs: first states the purpose in one sentence, second gives the use case and comparison to DOM scraping, third covers the two key constraints. Every sentence adds information; the most critical detail (what it inspects) is front-loaded. Zero filler.

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?

The tool has an output schema (indicated by has output schema: true), so return values are covered elsewhere. The description covers the only other operational gaps: truncation, buffer lifetime, and binary handling via file paths. For a read-only inspection tool with optional parameters, this is complete.

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 description coverage is 100%, so all four parameters are already documented. The description adds value by explaining when to use file paths ('for anything larger' than 5000 characters) and ties the truncation constraint to request_file_path/response_file_path. This supplements the schema without redundancy.

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 verb ('Inspect') and resource ('one network request') and enumerates exactly what is returned (URL, method, resource type, both bodies). It explicitly contrasts with list_network_requests ('find the page's own API call with list_network_requests, then read the JSON it already received here'), which distinguishes it from its sibling 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?

The description provides a concrete workflow: use list_network_requests to locate a request, then use this tool to read its JSON rather than scraping the DOM. It also gives situational guidance for large bodies (use file paths) and warns about response buffer lifetime. This is explicit when-to-use context that routes the agent correctly.

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

Deploy Server

Other Tools