Skip to main content
Glama
WhiteNightShadow

camoufox-reverse-mcp

by WhiteNightShadow
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

network_capture

Control browser network capture. Start, stop, clear, or check status, with URL filtering and response body capture options.

Instructions

Unified network capture control (v0.9.0).

Replaces start_network_capture / stop_network_capture.

Args: action: "start" — begin capturing network events "stop" — stop capturing (buffer retained) "clear" — clear the capture buffer "status" — return current capture state url_pattern: Glob pattern for "start" (default "**/*" captures all). capture_body: For "start" only; capture response bodies (more memory). max_body_size: For start; retained characters per response, 0..2000000. Playwright still reads the complete response before truncation. wait_timeout_ms: For stop; wait up to 30000ms for captured responses. New requests stop immediately; unfinished work is reported, not replayed. Clear cancels pending work; IDs remain monotonic until browser close.

Returns: dict with action result + current status snapshot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes
url_patternNo**/*
capture_bodyNo
max_body_sizeNo
wait_timeout_msNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.0
    • addedInput schema / properties / max_body_size
      Added value: +{
+  "default": 200000,
+  "title": "Max Body Size",
+  "type": "integer"
+}
    • addedInput schema / properties / wait_timeout_ms
      Added value: +{
+  "default": 0,
+  "title": "Wait Timeout Ms",
+  "type": "integer"
+}
  2. Addedv1.0.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses memory implications of capture_body, that Playwright reads full responses before truncation, that wait_timeout affects stop behavior, and that clear cancels pending work with monotonic IDs. This is strong behavioral disclosure.

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 well-structured, compact, and scannable. Each parameter is explained in a single line with relevant caveats, and the action list is clear without unnecessary prose.

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?

The description covers the core tool behavior, parameter semantics, and side effects, which is sufficient for correct invocation. It does not specify the exact shape of the returned status snapshot, but no output schema is required and the description states what the return represents.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description gives meaningful semantics for every parameter: url_pattern filtering, capture_body memory trade-off, max_body_size truncation behavior, and wait_timeout_ms stop behavior. This fully compensates for the sparse schema.

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 this is a unified control for network capture, enumerates the four action values, and distinguishes it from related sibling tools like list_network_requests and export_network_capture.

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 explains when to use start, stop, clear, and status, and notes that it replaces start_network_capture/stop_network_capture. It does not explicitly contrast with interception or listing tools, but the action enumeration provides enough guidance.

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