Skip to main content
Glama
frsorrentino

Chrome Bridge

by frsorrentino
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

monitor_network

Read-onlyIdempotent

Observe network requests in Chrome to capture XHR/fetch calls, browser assets, or WebSocket messages and export traffic as HAR for debugging.

Instructions

Monitor network requests. source=page: XHR/fetch hook (installed on first call); source=browser: all requests incl. static assets; source=websocket: connections and messages. format=har exports HAR 1.2. It only observes: to block, stub or rewrite requests use network_rules, to send one yourself http_request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
clearNoClear buffer after read
limitNoMost recent; buffer 1000
sinceNocursor from the previous read: only newer entries, nothing deleted
formatNohar exports HAR 1.2 for external toolinglines
sourceNopage: XHR/fetch only; browser: static assets too; websocket: connections and messagespage
tab_idNoTarget tab; omitted = last tab navigated in this session, else the active one

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.28.0
    • addedInput schema / properties / since
      Added value: +{
+  "description": "cursor from the previous read: only newer entries, nothing deleted",
+  "type": "string"
+}
  2. Changed2 schema fields changedv1.16.1
    • changedInput schema / properties / source / description
      Previous value: -"page sees XHR/fetch only; browser also sees static assets"New value: +"page: XHR/fetch only; browser: static assets too; websocket: connections and messages"
    • changedInput schema / properties / source / enum
      Previous value: -[
-  "page",
-  "browser"
-]New value: +[
+  "page",
+  "browser",
+  "websocket"
+]
  3. Changed3 schema fields changedv1.10.0
    • addedInput schema / properties / format / description
      Added value: +"har exports HAR 1.2 for external tooling"
    • addedInput schema / properties / source / description
      Added value: +"page sees XHR/fetch only; browser also sees static assets"
    • addedInput schema / properties / tab_id / description
      Added value: +"Target tab; omitted = last tab navigated in this session, else the active one"
  4. First observedv1.8.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds value beyond them by disclosing the side effect that the page hook is 'installed on first call' and reinforcing the observe-only contract ('It only observes'). It stops short of describing buffering/pagination behavior beyond what the schema notes.

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 tight clauses, front-loaded with the verb and resource, then modes, then alternatives. Zero filler; every phrase conveys routing or behavior information.

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 read-only observation tool with full annotation coverage and a complete schema, the description covers modes, output format, and sibling routing. It omits any hint about return shape (e.g. what lines/json/har contain), but with no output schema and safety fully declared, this is a minor gap.

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 every parameter is already documented in the schema; the description's source and format explanations largely restate the enum descriptions. Baseline 3 is appropriate since the schema does the heavy lifting.

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+resource ('Monitor network requests') and immediately decomposes the three source modes (page/browser/websocket), which distinguishes it from the many sibling read tools. An agent can tell exactly what this captures 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 Guidelines5/5

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

Explicitly routes the agent to alternatives by condition: 'to block, stub or rewrite requests use network_rules, to send one yourself http_request.' This is textbook when-to-use and when-to-use-something-else guidance, including the source selection criteria.

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