Skip to main content
Glama

browser_network_response

Read-onlyIdempotent

Retrieve the response body for a captured browser network request, with secret fields masked and binary data available as base64.

Instructions

Response body of a request from browser_network_requests (Network.getResponseBody), truncated to max_bytes (truncated). Secret fields masked by the extension, at any depth: JSON (access_token, refresh_token, id_token, token, password, secret, api_key, client_secret, authorization, session...) and forms (a=1&token=...); masked = number of masked values. A binary body is reported (binary, size) and returned as base64 only with include_binary=True.

Input Schema

NameRequiredDescriptionDefault
tab_idYesYour tab's id (from browser_new_tab, or a tab adopted with browser_adopt_tab).
max_bytesNo
request_idYes
include_binaryNo

Output Schema

NameRequiredDescriptionDefault
dataYes
statusYes
warningNoEmergency stop hotkey not held, or similar notice
untrusted_noteNoPage text that looks like instructions aimed at an AI

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv2.31.6
    • addedOutput schema / $defs
      Added value: +{
      +  "NetworkBody": {
      +    "additionalProperties": true,
      +    "description": "Response body. Secret fields masked (masked: how many); binary body: base64 only with include_binary.",
      +    "properties": {
      +      "base64Encoded": {
      +        "type": "boolean"
      +      },
      +      "binary": {
      +        "type": "boolean"
      +      },
      +      "body": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      },
      +      "dialog": {
      +        "$ref": "#/$defs/PageDialog"
      +      },
      +      "dialogOpened": {
      +        "type": "boolean"
      +      },
      +      "masked": {
      +        "type": "integer"
      +      },
      +      "message": {
      +        "type": "string"
      +      },
      +      "mimeType": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      },
      +      "note": {
      +        "type": "string"
      +      },
      +      "pendingDialogs": {
      +        "items": {
      +          "$ref": "#/$defs/PageDialog"
      +        },
      +        "type": "array"
      +      },
      +      "request_id": {
      +        "type": "string"
      +      },
      +      "size": {
      +        "type": "number"
      +      },
      +      "status": {
      +        "anyOf": [
      +          {
      +            "type": "integer"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      },
      +      "truncated": {
      +        "type": "boolean"
      +      },
      +      "url": {
      +        "type": "string"
      +      }
      +    },
      +    "title": "NetworkBody",
      +    "type": "object"
      +  },
      +  "PageDialog": {
      +    "additionalProperties": true,
      +    "description": "Dialog opened by the page (never accepted by the agent: browser_handle_dialog).",
      +    "properties": {
      +      "defaultPrompt": {
      +        "type": "string"
      +      },
      +      "message": {
      +        "type": "string"
      +      },
      +      "tabId": {
      +        "type": "integer"
      +      },
      +      "type": {
      +        "type": "string"
      +      },
      +      "url": {
      +        "type": "string"
      +      }
      +    },
      +    "title": "PageDialog",
      +    "type": "object"
      +  }
      +}
    • addedOutput schema / additionalProperties
      Added value: +true
    • addedOutput schema / description
      Added value: +"Response body of a recorded request."
    • addedOutput schema / properties / data
      Added value: +{
      +  "$ref": "#/$defs/NetworkBody"
      +}
    • removedOutput schema / properties / result
      Removed value: -{
      -  "title": "Result",
      -  "type": "string"
      -}
    • addedOutput schema / properties / status
      Added value: +{
      +  "const": "success",
      +  "type": "string"
      +}
    • addedOutput schema / properties / untrusted_note
      Added value: +{
      +  "description": "Page text that looks like instructions aimed at an AI",
      +  "type": "string"
      +}
    • addedOutput schema / properties / warning
      Added value: +{
      +  "description": "Emergency stop hotkey not held, or similar notice",
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "result"
      -]New value: +[
      +  "status",
      +  "data"
      +]
    • changedOutput schema / title
      Previous value: -"browser_network_responseOutput"New value: +"NetworkBodyAnswer"
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only cover safety (readOnly, idempotent, non-destructive); the description adds substantial behavior the agent could not otherwise know: truncation at max_bytes with a truncated flag, recursive secret masking across JSON keys (access_token, password, api_key, ...) and form-encoded bodies, a masked count, and binary bodies being reported as type+size but only returned as base64 when include_binary=True.

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-loads the core action in the first clause, then layers masking and binary behavior in the order an agent would need them. Some parenthetical fragments ('truncated to max_bytes (truncated)', 'masked = number of masked values') are compressed to the point of being cryptic.

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?

With an output schema present, return-value descriptions are unnecessary; the description instead covers the non-obvious behaviors (masking, truncation, binary gating) that shape how a caller interprets that output. Minor remaining gap: no mention of what happens when request_id is stale/unknown or the body has been evicted.

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 only 25% (only tab_id documented), so the description has to carry the load — and it mostly does: it defines max_bytes (truncation threshold), include_binary (gates base64 payloads), and the origin of request_id. The '(truncated)' parenthetical and the exact 'masked' return semantics are slightly ambiguous, and no default/guidance on choosing max_bytes is given.

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?

States a specific verb and resource — returns the response body of a request previously listed by browser_network_requests, naming the underlying CDP method (Network.getResponseBody). The explicit lineage to the sibling tool makes it unambiguous which of the two network tools an agent wants for bodies vs. request lists.

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?

Makes the workflow prerequisite clear: the request_id must come from browser_network_requests, and tab_id from browser_new_tab / browser_adopt_tab (per schema). It does not, however, contrast this with alternatives for retrieving page data (browser_content, browser_eval), so an agent in a 'get me the page data' scenario gets no explicit disambiguation.

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