BrowserMCP Extended

Overview Schema Source Related Servers Discussions Admin

browser_network_detail

Retrieve detailed data for a captured browser request by ID, including headers, URL, POST data, response body, timing, errors, and WebSocket frames, plus body availability and truncation flags.

Instructions

Read a captured request including headers, query URL, POST data, response body, timing, errors and WebSocket frames. Bodies can be unavailable or truncated; see bodyError and truncated fields.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "requestId": "<requestId>"
    },
    "name": "browser_network_detail"
  }
}

Input Schema

Name	Required	Description	Default
`tabId`	No	Tab to capture or inspect (active tab by default).
`requestId`	Yes	Exact id returned by browser_network_list

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Nov 2, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does disclose the most important failure mode: bodies may be unavailable or truncated, with bodyError and truncated fields to check. That is real behavioral context beyond the schema. It stops short of saying whether the request may have been evicted from the buffer or that capture must be running.

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?

Two sentences, no filler, and the enumeration of returned fields is front-loaded before the data-quality caveat. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read with no output schema, the field enumeration effectively substitutes for a return-value spec and the bodyError/truncated caveat covers the main edge case. What is missing is the precondition that a capture session must exist and how this relates to browser_network_list.

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 coverage is 100%, so both tabId and requestId are already documented, including that requestId comes from browser_network_list. The description adds no per-parameter meaning beyond that, which is the expected baseline when the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb ('Read') plus a concrete resource ('a captured request'), with an enumeration of what is returned (headers, POST data, response body, timing, errors, WebSocket frames). It is clearly the detail counterpart to browser_network_list, though the description itself never names that sibling — only the schema's requestId field does.

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

Usage Guidelines3/5

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

Usage is only implied: read one request by id. There is no explicit when-to-use, no statement that the id must come from browser_network_list, and no note that a capture session must be active. An agent can infer the workflow but is given no exclusions or alternatives.

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