Skip to main content
Glama
raultov

chrome-debug-mcp

by raultov
OverviewSchemaRelated ServersScoreDiscussions(1)
Rust
Local

get_network_logs

Audit API calls and debug network issues by retrieving intercepted HTTP/REST requests and WebSocket frames from Chrome's network cache, with filtering by URL, type, or payload.

Instructions

Retrieves intercepted HTTP/REST requests and WebSocket frames from network activity cache with filtering. Side effects: when 'clear' is true the cached requests and WebSocket frames are emptied after being returned. Prerequisites: requires active Chrome tab with network monitoring enabled. Returns: JSON array of requests/WebSocket frames with optional full details ('include_details' defaults to true; set false for summary only). Rate limits: none. Use this to audit API calls, debug network issues, inspect WebSocket traffic. Alternatives: browser DevTools Network tab, HAR file export.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
clearNoClear network cache after returning logs. Constraints: boolean. Interactions: when true, subsequent calls return only new traffic. Defaults to: false.
tab_idNoThe Tab ID of the target tab. Omit to use the active tab.
url_filterNoPartial URL match (case-insensitive). Constraints: non-empty string. Interactions: filters both REST and WebSocket URLs; empty string disables filtering. Defaults to: None (no URL filtering).
instance_idNoChrome instance id from open_instance/list_instances. Omit for the default instance.
type_filterNoTraffic type to include. Constraints: 'rest', 'websocket', or 'both' (case-insensitive). Interactions: limits results to specified type. Defaults to: "both".
include_detailsNoInclude full request/response details. Constraints: boolean. Interactions: when false, returns summary only (URL, method, status); when true, includes headers, bodies. Defaults to: true.
ws_content_filterNoWebSocket payload substring match (case-insensitive). Constraints: non-empty string. Interactions: applies only when type_filter includes 'websocket'; filters by payload content. Defaults to: None (no content filtering).
ws_direction_filterNoWebSocket frame direction filter. Constraints: 'sent', 'received', or 'both'. Interactions: applies only when type_filter includes 'websocket'. Defaults to: "both".

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed8 schema fields changedv1.3.2
    • removedInput schema / properties / clear / nullable
      Removed value: -true
    • removedInput schema / properties / include_details / nullable
      Removed value: -true
    • removedInput schema / properties / instance_id / nullable
      Removed value: -true
    • removedInput schema / properties / tab_id / nullable
      Removed value: -true
    • removedInput schema / properties / type_filter / nullable
      Removed value: -true
    • removedInput schema / properties / url_filter / nullable
      Removed value: -true
    • removedInput schema / properties / ws_content_filter / nullable
      Removed value: -true
    • removedInput schema / properties / ws_direction_filter / nullable
      Removed value: -true
  2. Addedv1.0.11
  3. Removedv1.0.10
  4. Changed6 schema fields changedv1.0.7
    • changedInput schema / properties / clear / description
      Previous value: -"If true, clears the internal network logs cache after retrieving the current logs. Use this to reset the state and only capture new traffic going forward."New value: +"Clear network cache after returning logs. Constraints: boolean. Interactions: when true, subsequent calls return only new traffic. Defaults to: false."
    • changedInput schema / properties / include_details / description
      Previous value: -"If true (default), returns full details including request/response headers, response bodies for REST, and full payloads for WebSockets. If false, returns a summary containing only the URL, method, status, statusText, and resourceType (or payload length for WS). Set to false when you just need to survey what requests were made without downloading all their contents."New value: +"Include full request/response details. Constraints: boolean. Interactions: when false, returns summary only (URL, method, status); when true, includes headers, bodies. Defaults to: true."
    • changedInput schema / properties / type_filter / description
      Previous value: -"Select the type of network traffic to retrieve. Valid options: \"rest\" (only REST/HTTP requests), \"websocket\" (only WebSocket frames), or \"both\" (default)."New value: +"Traffic type to include. Constraints: 'rest', 'websocket', or 'both' (case-insensitive). Interactions: limits results to specified type. Defaults to: \"both\"."
    • changedInput schema / properties / url_filter / description
      Previous value: -"Filter by URL content. Only requests or WebSocket connections whose URL contains this exact string (case-insensitive) will be returned. Leave empty to disable URL filtering."New value: +"Partial URL match (case-insensitive). Constraints: non-empty string. Interactions: filters both REST and WebSocket URLs; empty string disables filtering. Defaults to: None (no URL filtering)."
    • changedInput schema / properties / ws_content_filter / description
      Previous value: -"Filter WebSocket frames by their payload content. Only frames whose payload data contains this exact string (case-insensitive) will be returned."New value: +"WebSocket payload substring match (case-insensitive). Constraints: non-empty string. Interactions: applies only when type_filter includes 'websocket'; filters by payload content. Defaults to: None (no content filtering)."
    • changedInput schema / properties / ws_direction_filter / description
      Previous value: -"Filter WebSocket frames by their transmission direction. Valid options: \"sent\" (client to server), \"received\" (server to client), or \"both\" (default)."New value: +"WebSocket frame direction filter. Constraints: 'sent', 'received', or 'both'. Interactions: applies only when type_filter includes 'websocket'. Defaults to: \"both\"."
  5. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the transparency burden and meets it well. It discloses the destructive side effect of 'clear', the prerequisite of an active Chrome tab with network monitoring enabled, the absence of rate limits, and the default return detail level. This is strong behavioral disclosure beyond the raw 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?

The description is compact but information-dense, using labeled sections such as Side effects, Prerequisites, Returns, and Rate limits for scannability. The main capability is front-loaded and every sentence contributes useful 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 complex 8-parameter tool with no annotations and no output schema, the description covers prerequisites, side effects, return shape, rate limits, use cases, and alternatives. It is slightly light on precise return-field structure, but it is complete enough for reliable invocation.

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?

The schema already documents all 8 parameters at 100% coverage with defaults, constraints, and interactions, so the baseline is 3. The description mostly restates the include_details default and clear behavior rather than adding new parameter-level meaning beyond what the schema provides.

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 ('Retrieves') and names the exact resource ('intercepted HTTP/REST requests and WebSocket frames from network activity cache with filtering'). It clearly distinguishes this from sibling log tools like get_console_logs and get_performance_metrics by focusing on network traffic.

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 provides explicit use cases ('audit API calls, debug network issues, inspect WebSocket traffic') and names alternatives (browser DevTools Network tab, HAR file export). It does not spell out when not to use the tool or directly compare with sibling tools, but the context is clear enough for an agent to select it appropriately.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/raultov/chrome-debug-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server