FoxMCP

Overview Schema Source Related Servers Discussions Admin

requests_start_monitoring

Starts capturing future web requests that match specified URL patterns in a browser profile, returning a monitor ID for reading or stopping the capture.

Instructions

Start capturing future web requests matching URL patterns in a profile.

Start before triggering navigation or other traffic. Each call starts a monitor; use requests_list_captured to read an existing one instead. Keep the returned monitor_id for requests_list_captured, requests_get_content and requests_stop_monitoring; monitors cannot be listed. Omit tab_id to capture matching traffic across this profile.

Capturing uses memory. Stop when finished; stored captures remain readable until the profile disconnects. Client disconnection stops its monitors; profile disconnection clears monitors and captured data.

profile_id is required: obtain it from profiles_list. All object IDs are local to that profile; never reuse them in another profile.

Input Schema

Name	Required	Description
`tab_id`	No	Optional tab ID to monitor (if not provided, monitors all tabs)
`options`	No	Optional configuration for monitoring: - capture_response_bodies: bool (default: True) - max_body_size: int (default: 50000) — bytes kept per body; the full size is reported either way - content_types_to_capture: List[str] (default: ["application/json", "text/plain"]) — a body comes back as text only if its content type matches one of these and is text to begin with
`profile_id`	Yes
`url_patterns`	Yes	List of URL patterns to monitor (e.g., ["https://api.example.com/", "/api/*"])

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.6.0Nov 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses memory cost, that monitors cannot be listed, the full lifecycle (client disconnection stops monitors; profile disconnection clears monitors and captured data, but stored captures remain readable until then), and the requirement to stop when finished. It also states that object IDs are profile-local and must never be reused elsewhere.

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 purpose is front-loaded in the first sentence, and each subsequent sentence carries distinct operational information (ordering, sibling routing, lifecycle, ID provenance) rather than restating the name. Paragraphing separates the call contract from the cleanup caveats.

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

Completeness5/5

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

An output schema exists, so return values need no explanation, yet the description still flags the crucial monitor_id handoff to requests_list_captured, requests_get_content and requests_stop_monitoring. For a stateful monitoring-start tool with 4 params, nothing needed to invoke or clean up correctly is missing.

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

Parameters4/5

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

Schema coverage is 75 percent, and the description compensates for the gaps: profile_id has no schema description but the description says to obtain it from profiles_list, and tab_id omission is restated as capturing across the profile. It adds the monitor_id return-value contract used by three sibling tools. The remaining option fields (body size, content types) are left to the 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 first sentence states a specific verb (start capturing), resource (future web requests), and scope (matching URL patterns in a profile). It is immediately distinguishable from its siblings requests_stop_monitoring and requests_list_captured, which are named in the body.

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?

It explicitly tells the agent to start before triggering navigation or other traffic, and explicitly routes the agent away from this tool when reading an existing monitor: 'use requests_list_captured to read an existing one instead.' It also states the condition for omitting tab_id (capture across the profile).

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

Deploy Server