Skip to main content
Glama

get_network_logs

Retrieve and filter network traffic data from Chrome DevTools Protocol, including REST API calls and WebSocket frames, for debugging web applications.

Instructions

Retrieve intercepted network requests (REST) and WebSocket frames with optional advanced filtering. Use this tool to inspect API calls, page assets, and WebSocket traffic. It is highly recommended to use the available filters to avoid flooding the context window with unnecessary network data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ws_direction_filterNoFilter WebSocket frames by their transmission direction. Valid options: "sent" (client to server), "received" (server to client), or "both" (default).
type_filterNoSelect the type of network traffic to retrieve. Valid options: "rest" (only REST/HTTP requests), "websocket" (only WebSocket frames), or "both" (default).
clearNoIf 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.
include_detailsNoIf 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.
ws_content_filterNoFilter WebSocket frames by their payload content. Only frames whose payload data contains this exact string (case-insensitive) will be returned.
url_filterNoFilter 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.
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves 'intercepted' data (implying real-time capture), warns about potential context window flooding, and suggests filtering to manage output size. However, it lacks details on rate limits, permissions needed, whether data is persisted between sessions, or what happens if no network activity has occurred.

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 efficiently structured in two sentences. The first sentence states the purpose and key capability (filtering). The second provides usage context and a critical best-practice warning. Every word serves a purpose with no redundancy or fluff.

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

Completeness3/5

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

For a tool with 6 parameters, no annotations, and no output schema, the description is adequate but incomplete. It covers the core purpose and a critical usage consideration (filtering to manage output), but doesn't address behavioral aspects like data persistence, capture scope (e.g., only during a session), or what the return structure looks like. Given the complexity, more context would be helpful.

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 description coverage is 100%, so the schema fully documents all 6 parameters. The description adds minimal parameter-specific context beyond the schema—it mentions 'advanced filtering' and advises using filters to avoid context flooding, but doesn't provide additional semantic meaning for individual parameters. This meets the baseline for high schema coverage.

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 clearly states the tool's purpose: 'Retrieve intercepted network requests (REST) and WebSocket frames with optional advanced filtering.' It specifies the exact resources (network requests, WebSocket frames) and the action (retrieve with filtering), distinguishing it from sibling tools like get_console_logs or get_custom_events that handle different data types.

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 clear context for when to use this tool: 'to inspect API calls, page assets, and WebSocket traffic.' It also advises on best practices: 'highly recommended to use the available filters to avoid flooding the context window.' However, it doesn't explicitly state when NOT to use it or mention specific alternatives among siblings, keeping it from a perfect score.

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