camoufox-agent

browse_diagnose

Diagnose a page or session by collecting console errors, network timings and failures, Web Vitals, DOM stats, and SEO/accessibility/security audits to pinpoint performance and rendering issues.

Instructions

Developer diagnostics for a page or session: console and uncaught errors with stacks, network timings/sizes/failures/caching, Web Vitals and navigation timing, DOM stats, and an audit (SEO, accessibility, security headers, cookies, mixed content). Supports emulation (color scheme, timezone, geolocation, offline). Firefox has no Lighthouse/CDP profiling.

Input Schema

Name	Required	Description	Default
`os`	No	Optional OS to spoof. Can be 'windows', 'macos', or 'linux'. If not specified, will rotate between all OS types.
`url`	No	URL to diagnose (one-shot). Provide exactly one of url or sessionId.
`args`	No	Additional browser command-line arguments to pass to the browser. Rejected unless CAMOUFOX_MCP_ALLOW_UNSAFE_OPTIONS=1; denied args are always rejected.
`geoip`	No	Automatically detect geolocation based on IP address.
`proxy`	No	Proxy configuration for routing browser traffic through an HTTP(S) proxy. Proxy servers are checked against the same local-network URL policy as page requests.
`locale`	No	Browser locale (e.g., 'en-US', 'fr-FR').
`reload`	No	Sessions only: clear collected data and reload the page first for a clean measurement.
`saveAs`	No	Also save the full report to CAMOUFOX_MCP_FILES_DIR/exports/<saveAs>.
`window`	No	Set fixed window size [width, height] instead of random generation. An empty array [] is accepted and treated as if the window parameter was not specified.
`timeout`	No	Timeout in milliseconds for page load (5-300 seconds).
`headless`	No	Run browser in headless mode. Auto-detects best mode for environment if not specified.
`humanize`	No	Enable realistic cursor movements and human-like behavior for better stealth and anti-detection.
`sections`	No	Defaults to all: console (logs + uncaught errors), network (timings, sizes, failures), perf (navigation timing, Web Vitals, DOM stats), audit (SEO, a11y, security headers, cookies, mixed content).
`settleMs`	No	Extra time after load for vitals and late requests.
`viewport`	No	Custom viewport dimensions.
`emulation`	No	Context emulation for diagnosing how the page behaves under other conditions.
`sessionId`	No	Existing session. Data covers everything since the session started (or since the last reload:true).
`maxEntries`	No	Max console/network entries returned per list.
`block_webgl`	No	Block WebGL to prevent fingerprinting and tracking.
`block_images`	No	Block all images for faster loading, reduced bandwidth, and lightweight browsing.
`block_webrtc`	No	Block WebRTC entirely for enhanced privacy and stealth.
`disable_coop`	No	Disable Cross-Origin-Opener-Policy for sites that require it.
`enable_cache`	No	Cache pages, requests, etc. Uses more memory but improves performance when revisiting pages.
`waitStrategy`	No	Wait strategy for page load. Defaults to 'domcontentloaded'. 'load' waits for all resources, 'networkidle' waits for network activity to finish.	domcontentloaded
`captchaPolicy`	No	Challenge handling policy. 'detect' reports signals, 'pause' returns state for human action, 'fail' returns an error, 'attempt' returns enhanced challenge metadata, interactive elements, a bounded screenshot, and a suggested strategy. When CAPTCHA_AUTONOMOUS=true, responses are marked for LLM-assisted handling and include provider-specific challengePlaybook context when known.
`exclude_addons`	No	List of default addons to exclude (e.g., ['ublock_origin']). Rejected unless CAMOUFOX_MCP_ALLOW_UNSAFE_OPTIONS=1.
`includeConsole`	No	Include bounded page console diagnostics in the JSON response.
`includeNetwork`	No	Include bounded network diagnostics in the JSON response.
`stealthProfile`	No	Convenience profile for common Camoufox browser settings. Explicit options override profile values.	normal
`firefox_user_prefs`	No	Custom Firefox user preferences to set. Rejected unless CAMOUFOX_MCP_ALLOW_UNSAFE_OPTIONS=1; denied prefs are always rejected.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 29, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare openWorldHint=true and destructiveHint=false/readOnlyHint=false, so the description's job is to add context — and it does, by disclosing the exact diagnostic payloads, that emulation conditions can be applied, and the Firefox profiling limitation, which is a real capability boundary an agent would otherwise discover only by failing. It does not mention the saveAs side effect or that a one-shot url spins up a browser, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the payload inventory that an agent most needs to decide relevance, followed by capability and constraint notes. The comma-separated enumerations are dense but each item is load-bearing; no filler.

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?

An output schema exists and the schema fully documents all 30 parameters, so the description needn't restate return values or option syntax. It covers scope (page vs session), payload contents, and one platform limitation — enough for correct invocation, with only the write/side-effect profile (saveAs, browser launch) left implicit.

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% across 30 parameters, so the schema already documents url/sessionId exclusivity, sections, emulation, and timeout. The description reinforces the sections category and emulation capability but adds no format or constraint detail beyond the schema — the baseline 3 for a fully documented schema is appropriate.

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?

Names a specific resource (page or session diagnostics) and enumerates exactly what it collects: console/uncaught errors with stacks, network timings/sizes/failures/caching, Web Vitals, DOM stats, and a four-part audit. The 'page or session' framing distinguishes it from the pure session tools, but no sibling (browse_console, browse_network_summary, browse_inspect) is named, so the differentiation is inferred rather than stated.

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?

Usage is implied by the section list (use this when you want a combined console+network+perf+audit report) and by 'Firefox has no Lighthouse/CDP profiling', which warns about a browser-dependent limitation. There is no explicit when-to-use-this-vs-browse_console/browse_network_summary guidance and no exclusions or prerequisites, so an agent must infer routing.

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