Skip to main content
Glama
chrome-dev-mcp

chrome-dev-mcp

get_network_requests

Read-only

Retrieve HTTP requests captured from the connected Chrome tab, with filters for status, resource type, URL, or request ID, and optional header inspection to debug network activity.

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. In a bulk listing, a URL ending in … is truncated and not usable — query its requestId for it in full. size is compressed on-the-wire bytes; canceled marks an abort (e.g. navigating away), usually not a real failure.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of most-recent requests to return
statusNoFilter by response status class, or by outcome: `failed` = network error/blocked, `pending` = still in flight.
requestIdNoReturn only this request, including every hop of its redirect chain. Pair with headerKeys to inspect one request in full.
urlFilterNoCase-insensitive substring match on the full (untruncated) request URL
headerKeysNoReturn 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.
resourceTypeNoFilter by CDP resource type. Any casing is accepted.

Output Schema

NameRequiredDescriptionDefault
requestsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.0

TDQS

A4.6/5.0
Behavior5/5

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

Read-only is already covered by annotations, yet the description adds substantial extra context: capture-start timing, pruning on navigation with the new document request retained, one record per redirect hop keyed by requestId/hop, WebSocket frames excluded, and what `canceled` versus `failed` mean. That is exactly the kind of non-obvious behavior an agent cannot infer from readOnlyHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the return payload, then each subsequent sentence carries a distinct behavioral fact with no filler. It is dense — several independent caveats are packed into one paragraph — which costs some scannability but not correctness.

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?

An output schema exists so return values needn't be explained, yet field semantics (`size`, `canceled`, `hop`, truncated URLs) are covered anyway, along with capture-window limits and pruning rules. Nothing an agent needs to call this correctly or interpret results is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning on top: it explains the bulk-listing truncation behavior tied to `limit`, tells the agent to pair requestId with headerKeys for full detail, and clarifies that returned `size` is compressed on-the-wire bytes rather than a decoded length. It stops short of covering the status/resourceType filter trade-offs.

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 ('Return HTTP requests captured from the connected tab') and enumerates exactly which fields come back (method, URL, status, size, duration, initiator, failure reason). It also names a sibling (get_console_logs) to contrast scope, so an agent can distinguish it without opening the schema.

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?

Gives clear operational guidance: capture only starts at connect time, pre-connect history is unavailable (explicitly contrasted with get_console_logs), and truncated URLs must be re-queried by requestId. It does not state exclusions among the network siblings (e.g., when to use get_network_response_body instead), so it falls short of a full when/when-not/alternatives treatment.

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