Skip to main content
Glama

get_network_request

Retrieve detailed network request information by ID or URL from Firefox DevTools for debugging and analysis during browser automation.

Instructions

Get request details by ID. URL lookup as fallback.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoRequest ID from list_network_requests
urlNoURL fallback (may match multiple)
formatNoOutput format (default: text)

Implementation Reference

  • The main execution handler for the get_network_request tool. Fetches network requests from Firefox DevTools, looks up specific request by ID (primary) or URL (fallback with collision check), formats details including truncated headers to avoid token limits, and returns structured response in text or JSON format.
    export async function handleGetNetworkRequest(args: unknown): Promise<McpToolResponse> {
      try {
        const {
          id,
          url,
          format = 'text',
        } = args as { id?: string; url?: string; format?: 'text' | 'json' };
    
        if (!id && !url) {
          return errorResponse('id or url required');
        }
    
        const { getFirefox } = await import('../index.js');
        const firefox = await getFirefox();
    
        const requests = await firefox.getNetworkRequests();
        let request = null;
    
        // Primary path: lookup by ID
        if (id) {
          request = requests.find((req) => req.id === id);
          if (!request) {
            return errorResponse(`ID ${id} not found`);
          }
        } else if (url) {
          // Fallback: lookup by URL (with collision detection)
          const matches = requests.filter((req) => req.url === url);
    
          if (matches.length === 0) {
            return errorResponse(`URL not found: ${url}`);
          }
    
          if (matches.length > 1) {
            const ids = matches.map((req) => req.id).join(', ');
            return errorResponse(`Multiple matches, use id: ${ids}`);
          }
    
          request = matches[0];
        }
    
        if (!request) {
          return errorResponse('Request not found');
        }
    
        // Format request details - apply header truncation to prevent token overflow
        const details = {
          id: request.id,
          url: request.url,
          method: request.method,
          status: request.status ?? null,
          statusText: request.statusText ?? null,
          resourceType: request.resourceType ?? null,
          isXHR: request.isXHR ?? false,
          timestamp: request.timestamp ?? null,
          timings: request.timings ?? null,
          requestHeaders: truncateHeaders(request.requestHeaders),
          responseHeaders: truncateHeaders(request.responseHeaders),
        };
    
        if (format === 'json') {
          return jsonResponse(details);
        }
    
        return successResponse(JSON.stringify(details, null, 2));
      } catch (error) {
        return errorResponse(error instanceof Error ? error : new Error(String(error)));
      }
    }
  • Tool schema definition specifying name, description, and inputSchema for validation including id (primary), url (fallback), and format parameters.
    export const getNetworkRequestTool = {
      name: 'get_network_request',
      description: 'Get request details by ID. URL lookup as fallback.',
      inputSchema: {
        type: 'object' as const,
        properties: {
          id: {
            type: 'string',
            description: 'Request ID from list_network_requests',
          },
          url: {
            type: 'string',
            description: 'URL fallback (may match multiple)',
          },
          format: {
            type: 'string',
            enum: ['text', 'json'],
            description: 'Output format (default: text)',
          },
        },
      },
    };
  • src/index.ts:121-123 (registration)
    Registration of the get_network_request handler in the central toolHandlers Map, mapping tool name to its execution function for MCP server dispatching.
    // Network
    ['list_network_requests', tools.handleListNetworkRequests],
    ['get_network_request', tools.handleGetNetworkRequest],
  • src/index.ts:165-167 (registration)
    Registration of the getNetworkRequestTool schema in the allTools array, which is returned in response to MCP listTools requests.
    // Network
    tools.listNetworkRequestsTool,
    tools.getNetworkRequestTool,
  • Underlying FirefoxClient method getNetworkRequests() that retrieves the list of captured network requests from the NetworkEvents module, called by the tool handler.
    async getNetworkRequests(): Promise<any[]> {
      if (!this.networkEvents) {
        throw new Error('Not connected');
      }
      return this.networkEvents.getRequests();
    }
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that URL 'may match multiple' requests, which adds useful context about potential ambiguity. However, it fails to disclose critical behavioral traits such as whether this is a read-only operation (implied by 'get' but not explicit), error handling for invalid inputs, performance characteristics, or what the output includes (e.g., details like headers, status). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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 extremely concise with two short sentences: 'Get request details by ID. URL lookup as fallback.' It is front-loaded with the primary purpose and efficiently adds context without unnecessary words. Every sentence earns its place by clarifying the tool's function and usage nuance, making it highly effective for quick understanding.

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?

Given the context: no annotations, no output schema, 3 parameters with full schema coverage, and moderate complexity (a retrieval tool with fallback options), the description is partially complete. It covers the basic purpose and hints at parameter usage but lacks details on behavioral aspects (e.g., output format implications, error cases) and doesn't fully compensate for the absence of annotations. It's adequate for a simple tool but has clear gaps in providing a comprehensive understanding.

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 already documents all parameters (id, url, format) with descriptions and an enum for format. The description adds minimal value beyond the schema: it implies that 'id' is primary and 'url' is a fallback, and hints that URL matching might not be unique ('may match multiple'). However, it doesn't provide additional semantics like parameter interactions (e.g., if both id and url are provided) or default behavior for format. Baseline 3 is appropriate as the schema does most of 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?

The description clearly states the tool's purpose: 'Get request details by ID' specifies the verb (get) and resource (request details), and 'URL lookup as fallback' adds context about an alternative input method. It distinguishes from sibling tools like 'list_network_requests' by focusing on retrieving details for a specific request rather than listing multiple requests. However, it doesn't explicitly differentiate from other potential retrieval tools, keeping it at a 4 instead of a 5.

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?

The description implies usage guidelines by mentioning 'URL lookup as fallback,' suggesting that ID is the primary method and URL is secondary, and it references 'list_network_requests' as the source for IDs. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., no mention of when to prefer URL over ID or vice versa) and doesn't specify prerequisites or exclusions, such as needing an existing request ID from the sibling tool.

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/mozilla/firefox-devtools-mcp'

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