chrome-dev-mcp

Overview Schema Source Related Servers Discussions Admin

get_network_requests

Read-only

Retrieve HTTP requests captured from the connected Chrome tab, filterable by status, resource type, URL, and redirect hop, with method, size, and failure reason to diagnose network issues.

Instructions

Return HTTP requests captured from the connected tab — method, URL, resource type, status, transferred size, duration, initiator, and failure reason. Capture starts when this server connects to the tab: requests issued before that are NOT visible (unlike get_console_logs, which replays pre-connect history). Requests belonging to a previous page are pruned on navigation, mirroring the DevTools Network panel default; the new document request itself is kept. A redirect chain appears as one record per hop, sharing a requestId and distinguished by hop. WebSocket frames are not captured.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum number of most-recent requests to return
`status`	No	Filter by response status class, or by outcome: `failed` = network error/blocked, `pending` = still in flight.
`requestId`	No	Return only this request, including every hop of its redirect chain. Pair with headerKeys to inspect one request in full.
`urlFilter`	No	Case-insensitive substring match on the full (untruncated) request URL
`headerKeys`	No	Return only these headers, matched case-insensitively, on both requestHeaders and responseHeaders. Omit to return no headers. Pass ["*"] for every header — that is bounded only by `limit`, so use it with `requestId` or a small limit.
`resourceType`	No	Filter by CDP resource type. Any casing is accepted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`requests`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.4.0Sep 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the behavioral burden and does so richly. It discloses the capture start boundary, navigation pruning behavior, redirect-chain representation as one record per hop with shared requestId and `hop`, and the absence of WebSocket frames — all traits an agent cannot infer from annotations or schema.

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 sentences, every one earning its place: the first states core function and return fields, the second explains capture-window and navigation semantics with a sibling contrast, and the third covers redirects and exclusions. It is dense but highly scannable and front-loaded with the most essential information.

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 that an output schema exists, the description need not re-explain return values, and the 100% schema parameter coverage handles parameter documentation. The description adds the missing operational context — capture lifecycle, navigation pruning, redirect hop representation, and WebSocket exclusion — making it complete for correct invocation and result interpretation.

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%, and each parameter already has clear descriptions covering limit, status, requestId, urlFilter, headerKeys, resourceType, and enums. The tool description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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 and resource — 'Return HTTP requests captured from the connected tab' — and enumerates the exact fields returned (method, URL, resource type, status, transferred size, duration, initiator, failure reason). It also distinguishes itself from get_console_logs by noting the pre-connect history difference, making its purpose unmistakable among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly communicates when data is available (only after server connection), when it is not (pre-connect requests), and what happens across navigation (pruning). It also gives exclusions such as WebSocket frames. However, it does not explicitly state when to prefer this tool over closely related siblings like get_network_response_body or clear_captures, so it falls just short of full usage routing.

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