Which integrations are available for this server?

Provides real-time browser debugging tools for Firefox, enabling inspection of network traffic, DOM queries, console logs, and WebSocket frames via MCP. Provides real-time browser debugging tools for Firefox, enabling inspection of network traffic, DOM queries, console logs, and WebSocket frames via MCP.

How do I use Firefox Browser Bridge?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Firefox Browser Bridge show me recent network requests" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Firefox Browser Bridge

by minuchoi

Overview Schema Source Related Servers Discussions Admin

Python

Local

Firefox Browser Bridge

Note: This entire project — all code, tests, documentation, and configuration — was generated by Claude (Anthropic). No human-written code.

MCP server + Firefox extension that gives Claude Code real-time browser debugging tools.

What It Does

Connects Firefox to Claude Code via the Model Context Protocol, enabling Claude to inspect network traffic, query the DOM, read console logs, and capture WebSocket frames -- all from the CLI.

Available Tools

Network

Tool	Description
`get_network_requests`	List captured HTTP requests, filterable by URL pattern, method, status code, and content type
`get_request_details`	Get full headers, request body, response body, and timing for a specific request
`search_network`	Full-text search across all captured request URLs, headers, and bodies

Page

Tool	Description
`get_page_info`	Get the active tab's URL, title, and tab ID
`query_dom`	Query DOM elements by CSS selector (returns tag, text, attributes, outerHTML)
`get_page_html`	Get full page HTML or a specific element's HTML (truncated at 500 KB)
`get_screenshot`	Capture a PNG/JPEG screenshot of the monitored tab
`get_storage`	Get localStorage, sessionStorage, and cookies (including HttpOnly)

Interaction (requires the interact capability, off by default)

Tool	Description
`navigate`	Navigate the monitored tab to an http(s) URL
`reload`	Reload the monitored tab (optional cache bypass)
`click`	Click the first element matching a CSS selector
`fill`	Set an input/textarea/select/contenteditable value and fire input/change events

Diagnostics

Tool	Description
`get_capture_status`	Report what the extension is actually capturing: connection, monitored tab, capability toggles, per-tab hook presence (e.g. CSP-blocked), and buffer counts

Console

Tool	Description
`get_console_logs`	Get recent console log entries, filterable by level (log, warn, error, info, debug)

WebSocket

Tool	Description
`start_ws_capture`	Start capturing WebSocket frames matching a URL pattern
`stop_ws_capture`	Stop capturing WebSocket frames for a URL pattern
`get_ws_frames`	Retrieve captured frames, filterable by URL pattern and direction (sent/received)

Related MCP server: FoxBridge MCP

Architecture

Claude Code <── MCP stdio ──> Python Server <── WebSocket ──> Firefox Extension
                               (port 7865)

The system has two components:

Python MCP Server (src/mcp_server/) -- runs two async tasks: an MCP stdio server that exposes tools to Claude Code, and a WebSocket server on port 7865 that communicates with the extension.
Firefox Extension (extension/) -- a Manifest V2 background script that connects as a WebSocket client to the MCP server. It captures HTTP traffic passively via the webRequest API, with page-level XHR/fetch hooking as a fallback for response bodies that filterResponseData fails to capture (common with POST responses on servers that use connection: close). It performs DOM queries, console log capture, and WebSocket frame interception on demand by injecting content scripts.

Data flow: Claude calls an MCP tool, the server either queries its local in-memory stores (for network data) or sends a command to the extension via WebSocket (for DOM, console, and WS operations). The extension executes the command and responds. Request/response correlation uses UUID-based message IDs with a 5-second timeout.

Prerequisites

Python >= 3.12
uv (Python package manager)
Firefox >= 109

Quick Start

1. Clone the repository

git clone <repo-url>
cd firefox-extension

2. Install dependencies

uv sync

3. Load the Firefox extension

Open Firefox and navigate to about:debugging#/runtime/this-firefox
Click Load Temporary Add-on...
Select extension/manifest.json from the cloned repository
The extension badge shows ON (green) when connected to the MCP server, OFF (red) when enabled but not connected, and OFF (grey) when switched off with the popup's master toggle

4. Configure MCP in your project

Add a .mcp.json file to your project root (or merge into an existing one):

{
  "mcpServers": {
    "browser-bridge": {
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/firefox-extension", "python", "-m", "mcp_server.server"]
    }
  }
}

Replace /absolute/path/to/firefox-extension with the actual path to the cloned repository.

5. Restart Claude Code

The MCP tools appear automatically. You can verify by asking Claude to list its available tools.

Extension Controls

Click the extension icon in the Firefox toolbar to open the control panel. From here you can:

See the connection status (green dot = connected to MCP server, red = disconnected)
Flip the master on/off switch (labelled Extension) to fully activate or deactivate the extension. When off, it disconnects from the server and removes all traffic listeners and page hooks, so it has zero effect on browsing until switched back on. The setting persists across restarts.
Toggle individual capabilities on or off (only available while the extension is on and connected):

Toggle	Controls	MCP Tools Affected
Network Requests	HTTP traffic capture and storage	`get_network_requests`, `get_request_details`, `search_network`
DOM / HTML	Page queries, HTML, screenshots, storage	`get_page_info`, `query_dom`, `get_page_html`, `get_screenshot`, `get_storage`
Console Logs	Console output capture	`get_console_logs`
WebSocket Frames	WS message interception	`start_ws_capture`, `stop_ws_capture`, `get_ws_frames`
Interact	Click, type, and navigate (mutates the page; off by default)	`navigate`, `reload`, `click`, `fill`

When a capability is disabled, the corresponding MCP tools return a "capability disabled" error. Settings persist across browser restarts via browser.storage.local. get_capture_status is never gated, so diagnostics work even when everything else is off.

This is useful for limiting the amount of data flowing through the bridge -- for example, disable network capture when you only need DOM queries, or turn off everything except WebSocket frames during a targeted debugging session.

Usage Examples

Once everything is connected, you can ask Claude Code things like:

"Check the network requests for any failed API calls on this page"
"Query the DOM for all form input elements"
"Start capturing WebSocket frames for wss://api.example.com and show me what comes through"
"Show me the console errors from the current page"
"Search the captured network traffic for any requests containing 'auth'"
"Get the full response body of that 500 error request"
"Take a screenshot of the page" / "Show me the cookies and localStorage"
"Navigate to the login page, fill in the email field, and click submit" (needs the Interact toggle on)
"Why am I not seeing any network requests?" (uses get_capture_status)

Tool Reference

get_network_requests

List captured HTTP requests, newest first.

Parameter	Type	Required	Description
`url_pattern`	string	no	Regex pattern to match against URLs
`method`	string	no	HTTP method filter (GET, POST, etc.)
`status_code`	integer	no	HTTP status code filter
`content_type`	string	no	Content type substring filter (e.g. "json", "html")
`limit`	integer	no	Max results to return (default 50)

get_request_details

Get full details of a specific request.

Parameter	Type	Required	Description
`request_id`	string	yes	Request ID from `get_network_requests`

search_network

Full-text search across captured request URLs, headers, and bodies.

Parameter	Type	Required	Description
`query`	string	yes	Search string
`limit`	integer	no	Max results (default 50)

get_page_info

Get the active tab's URL, title, and tab ID. No parameters.

query_dom

Query DOM elements by CSS selector.

Parameter	Type	Required	Description
`selector`	string	yes	CSS selector to query

get_page_html

Get full page HTML or a specific element's HTML.

Parameter	Type	Required	Description
`selector`	string	no	CSS selector. If omitted, returns full page HTML

get_console_logs

Get recent console log entries from the current page.

Parameter	Type	Required	Description
`level`	string	no	Filter by level: log, warn, error, info, debug
`limit`	integer	no	Max entries (default 100)

get_screenshot

Capture a screenshot of the monitored tab. Returns an image (PNG by default).

Parameter	Type	Required	Description
`format`	string	no	"png" (default) or "jpeg"
`quality`	integer	no	JPEG quality 0-100 (default 80; ignored for png)

get_storage

Get the current page's localStorage, sessionStorage, and cookies (including HttpOnly cookies, which document.cookie cannot see). Large values are truncated. No parameters.

get_capture_status

Diagnose what the extension is capturing: connection state, monitored tab, capability toggles, whether the network/console/XHR hooks are actually present on the current tab (surfacing CSP-blocked injection), buffer counts, and server-side store totals. No parameters. Use this when a capture tool unexpectedly returns nothing.

navigate

Navigate the monitored tab to a URL. Only http/https URLs are allowed. Requires the interact capability.

Parameter	Type	Required	Description
`url`	string	yes	The http(s) URL to load

reload

Reload the monitored tab. Requires the interact capability.

Parameter	Type	Required	Description
`bypass_cache`	boolean	no	Hard reload bypassing the cache (default false)

click

Click the first element matching a CSS selector. Fires a real DOM click event. Requires the interact capability.

Parameter	Type	Required	Description
`selector`	string	yes	CSS selector of the element to click

fill

Set the value of an input, textarea, select, or contenteditable element and fire input/change events (using the native value setter so frameworks like React register the change). Requires the interact capability.

Parameter	Type	Required	Description
`selector`	string	yes	CSS selector of the field
`value`	string	yes	Value to set

start_ws_capture

Start capturing WebSocket frames for connections matching a URL pattern. Frames are not captured by default -- you must call this first.

Parameter	Type	Required	Description
`url_pattern`	string	yes	Pattern to match WebSocket connection URLs

stop_ws_capture

Stop capturing WebSocket frames.

Parameter	Type	Required	Description
`url_pattern`	string	yes	The same pattern passed to `start_ws_capture`

get_ws_frames

Retrieve captured WebSocket frames.

Parameter	Type	Required	Description
`url_pattern`	string	no	Filter by connection URL pattern
`direction`	string	no	Filter by direction: "sent" or "received"
`limit`	integer	no	Max frames (default 100)

How It Works

The MCP server (src/mcp_server/server.py) launches two concurrent async tasks:

MCP stdio server -- communicates with Claude Code over stdin/stdout using the MCP protocol. Exposes 17 tools.
WebSocket server -- listens on ws://127.0.0.1:7865 for the Firefox extension to connect. Connections whose Origin is not a moz-extension:// origin are rejected, so a web page cannot open the port and impersonate the extension.

The Firefox extension runs a persistent background script that:

Connects as a WebSocket client and auto-reconnects with exponential backoff on disconnection.
Passively captures all HTTP traffic using Firefox's webRequest API (listeners are registered dynamically and only active when network capture is enabled). Response bodies are captured via filterResponseData (primary) with two fallback mechanisms: cache-based re-fetch for GET requests, and page-level XHR/fetch hooking via dynamically registered content script (document_start) for POST/PUT/DELETE/PATCH responses where filterResponseData produces no data. Body capture (filterResponseData) is restricted to xmlhttprequest resource types (XHR/fetch API calls) -- document loads, scripts, stylesheets, images, fonts, and other non-API traffic skip body capture entirely, which dramatically reduces IPC overhead. Monitoring is scoped to a single tab (the active tab, re-selected if the monitored tab closes). The hook communicates with the content script relay via synchronous DOM attribute + dispatchEvent, avoiding async postMessage races with page navigation. URLs are resolved to absolute before correlation. Captured data is stored in in-memory ring buffers -- 500 requests per tab, up to 20 tabs.
On demand, injects into the active tab to perform DOM queries, console log interception, and WebSocket frame capture. Console and WebSocket hooks run in the page world via injected <script> tags (a content-script console/window.WebSocket override does not intercept the page's own calls under Firefox Xray isolation); console logs are read back through window.wrappedJSObject.
Correlates requests and responses using UUID-based message IDs with asyncio Futures (5-second timeout on the server side).

Only a single extension connection is allowed at a time.

Key Files

File	Purpose
`src/mcp_server/server.py`	Entry point; wires up MCP + WebSocket servers
`src/mcp_server/tools.py`	MCP tool definitions and dispatch logic
`src/mcp_server/ws_bridge.py`	WebSocket server, connection manager, message routing
`src/mcp_server/request_store.py`	In-memory ring buffer stores for requests and WS frames
`extension/background.js`	All extension logic: WS client, network capture, DOM tools, WS frame capture
`extension/xhr_hook_content.js`	Content script for XHR/fetch response body capture (registered at `document_start`)

Troubleshooting

Extension badge shows "OFF" The MCP server is not running. Start it manually to verify:

uv run python -m mcp_server.server

Tools return timeout errors The extension may have disconnected. Check the Firefox browser console (Ctrl+Shift+J) for WebSocket connection errors. Reload the extension from about:debugging.

No network data appears Make sure the extension is loaded and the badge shows "ON". Check that the Network Requests toggle is enabled in the extension popup. Network capture begins automatically when the extension connects -- navigate to a page or refresh to generate traffic.

DOM queries fail on certain pages Content script injection is blocked on privileged pages (about:*, moz-extension:*, and other restricted URLs). This is a Firefox security restriction.

Console logs are empty on first call Console log capture requires injecting a page-world hook, which happens when the console capability is toggled on, when the monitored tab is selected/navigates, or on the first get_console_logs call. Logs generated before the hook is installed are not captured. It is also injected as an inline <script>, so a strict Content-Security-Policy (script-src without 'unsafe-inline') blocks it, same as the XHR/fetch hook.

POST response bodies are missing on pages with strict CSP The XHR/fetch hook fallback injects an inline <script> tag into the page. Pages with a strict Content-Security-Policy that blocks inline scripts (script-src without 'unsafe-inline') will prevent the hook from running. In that case, POST response bodies may be missing if Firefox's filterResponseData also fails (common with servers that send connection: close + gzip). GET responses are unaffected as they use a separate cache-based fallback.

Response bodies show garbled text This can happen if the response uses brotli (br) content-encoding and Firefox's filterResponseData delivers raw compressed bytes instead of decompressed data. This is rare in practice. The XHR/fetch hook handles JSON, XML (responseType: "document"), and plain text responses correctly; binary formats (arraybuffer, blob) are skipped.

Security Notes

The WebSocket server binds to 127.0.0.1 only -- not accessible from the network. It also rejects connections whose Origin header is not moz-extension://..., so a malicious web page cannot open the port, impersonate the extension, and feed fabricated data to Claude. Note there is no shared-secret handshake, and captured XHR/fetch bodies relayed from the page world should be treated as page-controlled data.
No data is persisted to disk. All captured data lives in memory and is lost when the server stops.
The extension requires broad permissions (<all_urls>, webRequest, webRequestBlocking, tabs, storage) to capture network traffic across all sites. This is inherent to the functionality. However, all webRequest listeners and the XHR/fetch content script are only active when the corresponding capability is enabled — when disabled, the extension has near-zero overhead.
Use the extension popup toggles to limit data exposure -- disable capabilities you don't need.
The extension is loaded as a temporary add-on and must be re-loaded after each Firefox restart.

License

MIT

Available Tools

17 tools

clickB

Click the first element matching a CSS selector on the monitored tab. Requires the 'interact' capability.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	CSS selector to click

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It only states 'Click the first element... on the monitored tab,' omitting important behavioral details such as whether it waits for the element to be interactable, scrolls into view, triggers events, or handles failures (e.g., element not found).

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?

Two concise sentences: one for the action, one for the requirement. No unnecessary words or repetition, making it easy to parse quickly.

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 simple one-parameter tool, the description is adequate but lacks edge-case context (e.g., behavior when selector matches multiple elements, timeout, or error handling). Without annotations or output schema, more completeness could benefit the agent.

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 coverage is 100% with a clear description ('CSS selector to click'). The tool description adds no further meaning beyond what the schema already provides, meeting the baseline for high 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 clicks the first element matching a CSS selector on the monitored tab. The verb 'click' and resource 'element matching CSS selector' are specific and distinguish it from sibling tools like query_dom (query) or fill (form input).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Only a capability requirement ('Requires the interact capability') is provided. No guidance on when to use this tool versus alternatives (e.g., when a simple click is needed vs. form fills or navigation), nor any conditions that might make it unsuitable.

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

fillA

Set the value of an input, textarea, select, or contenteditable element matching a CSS selector and fire input/change events. Requires the 'interact' capability.

ParametersJSON Schema

Name	Required	Description	Default
`value`	Yes	Value to set
`selector`	Yes	CSS selector of the field

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses that it fires input/change events, which is good. However, it does not specify behavior on hidden elements, error handling, or whether it scrolls to the element. The disclosure is adequate but not comprehensive.

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 two sentences, front-loading the primary action and adding a necessary capability requirement. No unnecessary words.

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?

For a simple form-fill tool with only two parameters and no output schema, the description is largely complete. It could mention what happens if the selector matches no element or multiple elements, but given the tool's simplicity, the current level is nearly sufficient.

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?

Although schema coverage is 100% with basic descriptions, the tool description adds significant meaning by specifying the valid element types (input, textarea, etc.) and the event-firing behavior. This clarifies the purpose of the 'value' parameter beyond 'Value to set'.

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 action ('Set the value'), the target element types ('input, textarea, select, or contenteditable'), and the side effect ('fire input/change events'). This distinguishes it from sibling tools like 'click' or 'query_dom'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a prerequisite ('Requires the 'interact' capability') but provides no guidance on when to use this tool versus alternatives, or when not to use it. There is no explicit context about use cases or exclusions.

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

get_capture_statusA

Diagnose what the extension is actually capturing right now: connection state, monitored tab, capability toggles, whether the network/console/XHR hooks are present on the current tab (e.g. blocked by CSP), and buffer counts. Use this when a capture tool unexpectedly returns nothing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the kind of diagnostic info returned (e.g., blocked by CSP, buffer counts). Does not explicitly state side effects, but as a diagnostic tool it is likely read-only.

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?

The description is a single, informative sentence that front-loads the purpose and lists key elements. Could be slightly more concise, but overall efficient.

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?

For a zero-parameter diagnostic tool with no output schema, the description adequately describes the return value and use cases. Differentiates well from 17 siblings.

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?

No parameters exist, and schema coverage is 100%. Description adds value by explaining what the output represents without needing parameter documentation, earning baseline 4.

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 uses specific verbs ('diagnose') and resources ('extension capture status') and lists concrete attributes (connection state, monitored tab, etc.), clearly distinguishing from sibling tools that retrieve specific data.

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 explicitly states when to use: 'Use this when a capture tool unexpectedly returns nothing.' It does not mention when not to use, but the use case is clear.

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

get_console_logsB

Get recent console log entries from the current page. Only available after the first query triggers injection.

ParametersJSON Schema

Name	Required	Description	Default
`level`	No	Filter by log level: log, warn, error, info, debug
`limit`	No	Max entries (default 100)

TDQS

B3.4/5.0

Behavior2/5

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

Without annotations, description only discloses availability constraint; no side effects, return format, or clearing 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?

Two sentences, front-loaded with purpose, no wasted words.

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

Completeness2/5

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

No output schema, and description omits return values or structure. For a 2-param tool with simple functionality, still needed.

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 coverage is 100% with descriptions; description adds no extra meaning beyond 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?

Clear verb 'Get' and resource 'console log entries' with scope 'current page'. Distinguishes from sibling tools like get_network_requests.

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?

Mentions prerequisite 'Only available after the first query triggers injection', but lacks when-to-use vs alternatives or exclusions.

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

get_network_requestsB

List captured network requests from Firefox. Filterable by URL regex pattern, HTTP method, status code, and content type. Returns newest first.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results to return (default 50)
`method`	No	HTTP method filter (GET, POST, etc.)
`tab_id`	No	Filter by tab ID. Omit for all tabs.
`status_code`	No	HTTP status code filter
`url_pattern`	No	Regex pattern to match against URLs
`content_type`	No	Content type substring filter (e.g. 'json', 'html')

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that results are 'newest first' and that it is filterable. However, it does not mention important behavioral aspects like read-only nature or session requirements.

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 no wasted words. It is front-loaded with the primary action, followed by filtering options and sorting order, all in two sentences.

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?

For a list tool with 6 filter parameters and no output schema, the description covers the core functionality and sorting. However, it lacks details on pagination or behavior when capture is inactive, but overall it is adequate.

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 coverage is 100%, so the schema already describes each parameter. The description adds no additional semantics beyond listing the filterable fields, which aligns with the baseline of 3.

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 states 'List captured network requests from Firefox', which is a clear verb+resource pair. The filtering options are also mentioned. However, it does not explicitly distinguish this tool from sibling tools like 'search_network' or 'get_request_details'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites or scenarios where this tool is preferred.

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

get_page_htmlA

Get the full page HTML or a specific element's HTML. Truncated at 500KB.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	No	Optional CSS selector. If omitted, returns full page HTML.

TDQS

A3.8/5.0

Behavior3/5

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

The description discloses the 500KB truncation limit, which is useful. However, it does not mention if the tool has side effects, requires permissions, or handles errors (e.g., invalid selectors). With no annotations, the description carries full burden but falls short on these aspects.

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 sentences, no fluff, and the key functionality is front-loaded.

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?

For a simple tool with one optional parameter and no output schema, the description covers the core behavior and the critical truncation detail. It could mention error handling and return format, but is largely adequate.

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 coverage is 100% and the parameter description is already clear. The tool description adds minimal additional semantic value, mainly restating the schema's information.

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 retrieves full page HTML or a specific element's HTML, with a truncation limit. This is distinct from sibling tools like get_network_requests or get_screenshot.

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?

No guidance on when to use this tool versus alternatives such as query_dom for DOM queries or get_screenshot for visual capture. The description implies usage but does not explicitly exclude other tools.

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

get_page_infoA

Get the current active tab's URL, title, and tab ID. If a monitored tab is set in the extension popup, returns that tab's info.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/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. It discloses the data returned and the conditional behavior (active vs monitored tab), but does not explicitly state non-destructive nature, permissions, or rate limits. Adequate but not comprehensive.

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?

Two concise sentences with no wasteful content. The information is front-loaded and easy to parse.

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?

Given no parameters, no output schema, and no annotations, the description is relatively complete. It explains the output and behavior. However, it could be enhanced by specifying the return format or confirming no side effects.

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?

There are zero parameters, so the baseline is 4. The description does not need to add parameter meaning, and it correctly implies no parameters are required.

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 that the tool retrieves the current active tab's URL, title, and tab ID, and mentions an alternative behavior when a monitored tab is set. This distinguishes it from sibling tools like get_page_html or navigate.

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 implies usage for obtaining tab metadata, but does not explicitly state when to use this tool over alternatives like get_page_html for content or get_console_logs for logs. The context is clear but lacks exclusions or alternatives.

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

get_request_detailsA

Get full details of a specific captured request: headers, request body, response body, timing.

ParametersJSON Schema

Name	Required	Description	Default
`request_id`	Yes	The request ID from get_network_requests

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided; description only states it gets details, missing any mention of side effects, permissions, or error behavior. Does not disclose whether it reads or modifies state, though read-only is reasonable.

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?

Single sentence, front-loaded with purpose and contents, no extraneous words.

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?

Lists key return fields (headers, request body, response body, timing) despite no output schema. Lacks format specification but sufficient for a detail retrieval tool.

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 coverage is 100% with a clear description referencing get_network_requests. Tool description adds no additional parameter details beyond schema, but baseline 3 is appropriate.

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?

Description clearly defines the tool as retrieving full details of a captured request, specifying contents: headers, request body, response body, timing. Distinguishes from sibling tools like get_network_requests and search_network.

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?

Implies usage after obtaining a request ID from get_network_requests, but no explicit when-to-use, exclusions, or comparisons to alternatives like search_network.

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

get_screenshotA

Capture a screenshot of the current (monitored) tab. Returns a PNG by default, or JPEG to reduce size.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Image format (default png)
`quality`	No	JPEG quality 0-100 (ignored for png, default 80)

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description must bear full transparency burden. It does not explicitly state that the operation is read-only or non-destructive. While capturing a screenshot is generally safe, the lack of explicit disclosure about side effects or permissions limits transparency.

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?

Two sentences: first states purpose, second adds format detail. No wasted words, front-loaded with key action. Optimal length for this simple tool.

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?

For a simple tool with two optional parameters and no output schema, the description covers essential behavior. Minor omission: doesn't specify if screenshot captures viewport or full page, but this is acceptable given common defaults.

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 covers both parameters with descriptions. The description adds context about PNG/JPEG defaults and size trade-off, enhancing understanding of format and quality parameters beyond the schema enums and integer range.

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 it captures a screenshot of the current monitored tab, with specific output formats. This verb-resource pairing is unambiguous and distinguishes it from sibling tools focused on network, page info, or DOM operations.

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 implies usage for visual capture, which is distinct from data retrieval tools. However, it does not explicitly state when not to use it or mention alternative tools like get_page_info for textual content. Still, the context is clear.

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

get_storageA

Get the current page's localStorage, sessionStorage, and cookies (including HttpOnly cookies). Useful for debugging auth/session state. Large values are truncated.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description fully discloses key behaviors: it includes HttpOnly cookies (usually inaccessible) and mentions that large values are truncated. This is valuable transparency. No side effects are described, but as a read operation, this is sufficient.

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 two sentences, front-loading the action, and every sentence provides necessary information. There is no redundancy or verbosity.

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?

Given no output schema, the description explains what the tool retrieves and notes truncation. However, it does not specify the return format (e.g., separate objects per storage type). Still, it is complete enough for an agent to understand its purpose and usage.

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?

The tool has zero parameters, and the schema coverage is 100% (empty). Per guidelines, a baseline of 4 is appropriate. The description adds no parameter details because none exist, and it correctly focuses on what the tool retrieves.

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 starts with 'Get' and explicitly lists the resources: localStorage, sessionStorage, and cookies. It clearly distinguishes this tool from sibling tools like get_network_requests or query_dom, which serve different purposes.

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 states it is 'useful for debugging auth/session state,' providing clear context for when to use this tool. However, it does not explicitly mention when not to use it or suggest alternative tools.

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

get_ws_framesB

Get captured WebSocket frames. Must call start_ws_capture first.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max frames (default 100)
`tab_id`	No	Filter by tab ID. Omit for all tabs.
`direction`	No	Filter by frame direction
`url_pattern`	No	Filter by connection URL pattern

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, and the description only restates the purpose and precondition. It does not disclose any behavioral traits such as what happens if capture hasn't started or if no frames are available, which is a significant gap for a data retrieval tool.

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?

Two concise sentences with no redundant information. Every word serves a purpose.

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

Completeness2/5

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

Given the absence of an output schema and the presence of multiple optional parameters, the description is too minimal. It does not clarify the return format or behavior, such as whether frames are returned in order or how limit interacts with other filters.

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 coverage is 100%, so the schema already describes each parameter. The description adds no additional meaning beyond the schema, meeting the baseline.

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 action (Get) and resource (captured WebSocket frames). It distinguishes from related siblings like get_network_requests, though it could be more explicit about differentiation.

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?

Provides a clear precondition: 'Must call start_ws_capture first.' This tells the agent when to use the tool, though it doesn't elaborate on alternative scenarios.

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

navigateA

Navigate the monitored tab to a URL (http/https only). Requires the 'interact' capability to be enabled in the popup.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The http(s) URL to load

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It discloses that navigation changes the tab's location and requires 'interact' capability, but missing details on loading behavior, error handling, or state changes.

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?

Two sentences, no wasted words. The action and key constraint are front-loaded, making it easy for an agent to parse quickly.

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?

For a simple navigation tool with one parameter and no output schema, the description covers the purpose, URL constraint, and a capability requirement. Missing behavioral details like page load wait, but adequate overall.

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?

The single parameter 'url' is described with the constraint 'http/https only', adding meaning beyond the schema's basic string description. Since schema coverage is 100%, baseline is 3, but the constraint raises it.

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 action 'Navigate', the resource 'monitored tab', and the constraint 'http/https only'. This is a specific verb+resource combination that distinguishes it from sibling tools like 'reload' or 'click'.

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 mentions a prerequisite ('Requires the ‘interact’ capability'), which gives context for when the tool can be used. However, it does not explicitly state when to use this tool versus alternatives like 'reload' or 'get_page_info', though the domain is clear.

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

query_domA

Query DOM elements on the current page by CSS selector. Returns tag, text content, attributes, and outerHTML for up to 50 matching elements.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	CSS selector to query

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose all behavioral traits. It mentions a limit of 50 elements and the fields returned, but does not address error handling (e.g., invalid selector, no matches), performance impact, or state modification. For a read-only query, this is adequate but could be more thorough.

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 two sentences, front-loaded with the core action and result. Every sentence adds value without any fluff or repetition.

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?

Given the simple schema (1 required parameter, no output schema), the description is fairly complete. It states the query method, return fields, and element limit. However, it lacks details on edge cases (e.g., no matches) or additional constraints, making it adequate but not fully comprehensive.

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 coverage is 100% with the only parameter 'selector' having a description 'CSS selector to query'. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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 verb ('Query'), resource ('DOM elements'), method ('by CSS selector'), and return data ('tag, text content, attributes, and outerHTML for up to 50 matching elements'). It effectively distinguishes from sibling tools like 'get_page_html' (full page HTML) and 'get_page_info' (page metadata).

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 implies usage for querying specific DOM elements on the current page with CSS selectors. While it provides clear context, it does not explicitly state when to use this tool versus alternatives (e.g., 'get_page_html' for full source) or when not to use it. However, the context from sibling tool names helps differentiate.

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

reloadA

Reload the monitored tab. Requires the 'interact' capability.

ParametersJSON Schema

Name	Required	Description	Default
`bypass_cache`	No	Bypass the cache (hard reload). Default false.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden. It discloses the capability requirement but does not mention any side effects (e.g., loss of page state, scroll position). The behavior is standard, so the minimal disclosure is adequate.

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, consisting of one sentence plus a requirement note. It is front-loaded with the action and is free of any superfluous text.

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?

For a simple tool with one optional parameter and no output schema, the description covers the essential action and a capability requirement. It could mention the effect on page state or network, but it is sufficient for the tool's simplicity.

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 describes the optional 'bypass_cache' parameter. The description adds no further meaning beyond what the schema provides, resulting in baseline score.

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 'Reload the monitored tab,' which is a specific verb and resource. It distinguishes from siblings like navigate or click by focusing on the reload action.

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 mentions the prerequisite 'interact' capability but does not provide explicit guidance on when to use reload versus alternatives like navigate. It implies usage for refreshing the current page.

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

search_networkA

Full-text search across all captured request URLs, headers, and bodies.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results (default 50)
`query`	Yes	Search string
`tab_id`	No	Filter by tab ID. Omit for all tabs.

TDQS

A3.5/5.0

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. It does not disclose any behavioral traits like read-only vs. destructive, rate limits, or impact on captured data. The description only describes the search scope without behavioral context.

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?

Single sentence that front-loads the action ('Full-text search') and includes the key resource scope. No wasted words.

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?

The description covers the basic purpose but lacks details on return format, result ordering, pagination (though limit parameter is present), or edge cases. Without output schema, more context would be helpful for completeness.

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 100% but descriptions are minimal. The tool description adds value by specifying the search scope (URLs, headers, bodies), which is not in the schema parameter descriptions. This provides meaningful context beyond 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 description clearly states it performs full-text search across request URLs, headers, and bodies. This is a specific verb-resource combination that distinguishes it from siblings like get_network_requests (which likely retrieves but doesn't search) and other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as get_network_requests or other search tools. The description only states the functionality without clarifying exclusive use cases or prerequisites.

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

start_ws_captureA

Start capturing WebSocket frames for connections matching the given URL pattern. Frames are NOT captured by default — call this first to enable capture.

ParametersJSON Schema

Name	Required	Description	Default
`url_pattern`	Yes	Glob/regex pattern to match WS connection URLs

TDQS

A4/5.0

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. It discloses that frames are not captured by default and that this tool enables capture, but it does not explain side effects (e.g., idempotency, what happens if called multiple times) or any prerequisites.

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 concise with two sentences, front-loading the key action and adding a critical usage note. Every sentence adds value.

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?

For a simple tool with one required parameter, the description is largely complete. It could optionally mention that capture must be stopped later, but the sibling tools cover that. Overall, adequate.

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 coverage is 100%, and the parameter description in the schema already explains the URL pattern. The tool description adds only 'matching the given URL pattern,' which does not significantly enhance understanding beyond 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 description clearly states the action ('Start capturing') and the resource ('WebSocket frames for connections matching the given URL pattern'). It effectively distinguishes from sibling tools like stop_ws_capture and get_ws_frames.

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 explicitly notes that 'Frames are NOT captured by default — call this first to enable capture,' providing clear guidance on when to use the tool. However, it does not discuss alternatives or when not to use it, which could be improved.

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

stop_ws_captureA

Stop capturing WebSocket frames for the given URL pattern.

ParametersJSON Schema

Name	Required	Description	Default
`url_pattern`	Yes	The same pattern passed to start_ws_capture

TDQS

A4.1/5.0

Behavior4/5

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

Simple and clear: stops the capture. No annotations provided, but the description accurately conveys the single action without ambiguity. However, it omits potential side effects like whether captured data is retained.

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?

One concise sentence that front-loads the purpose. Every word is necessary and informative.

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?

For a simple 1-parameter tool with clear siblings, the description is complete. No output schema needed. Usage context is 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 has 100% coverage for the single parameter, and the description adds no extra meaning beyond the schema's own description.

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?

Description clearly states the action 'stop' and the resource 'capturing WebSocket frames' for a given URL pattern. It distinguishes itself from sibling tools like 'start_ws_capture' and 'get_ws_frames'.

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?

No explicit when-to-use or when-not-to-use guidance. It is implied as the complement to 'start_ws_capture', but missing prerequisites or alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

17 tool updatesv0.1.0Jul 29, 2026
- First observedclick
- First observedfill
- First observedget_capture_status
- First observedget_console_logs
- First observedget_network_requests
- First observedget_page_html
- First observedget_page_info
- First observedget_request_details
- First observedget_screenshot
- First observedget_storage
- First observedget_ws_frames
- First observednavigate
- First observedquery_dom
- First observedreload
- First observedsearch_network
- First observedstart_ws_capture
- First observedstop_ws_capture

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-07-29 07:50 across 17 tools

Disambiguation5/5

Each tool targets a distinct aspect of browser debugging: network requests, DOM, console, storage, interaction, and WebSocket. Even tools dealing with similar domains (e.g., get_network_requests vs. search_network) have clearly differentiated purposes.

Naming Consistency4/5

Naming mostly follows a verb_noun pattern with snake_case, but there is some inconsistency: some tools start with 'get_' while others are bare verbs like 'navigate' or 'click'. However, the pattern is clear and readable.

Tool Count5/5

17 tools is well-scoped for a browser automation/debugging bridge, covering network, DOM, storage, console, screenshots, WebSocket, navigation, and interaction without being overwhelming.

Completeness5/5

The tool set covers nearly all essential operations for inspecting and controlling a Firefox tab: capturing network requests (including WebSocket), querying/modifying DOM, reading storage, taking screenshots, and interacting with the page. Missing capabilities like keyboard events are minor.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

sncro A
io.github.scottconfusedgorilla
Live browser debugging for AI assistants — DOM, console, network via MCP.
Browser Automation Developer Tools Monitoring
2
TabfleetOAuth
com.tabfleet
Launch, inspect, control, and share isolated cloud browsers for your agents.
Agent Orchestration Browser Automation
1
AgentSEO B
dev.agentseo.www
Live SEO workflow tools for Claude Code, Codex, and AI agents.
Marketing Browser Automation
454
claude-context-bridgeOAuth
io.github.PhoenixFeuer32
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Communication Knowledge & Memory Developer Tools
2

Related MCP Servers

gotham-browser
Browser Automation Web Scraping
gotham-os
F
license
Not graded
quality
B
maintenance
Enables Claude Code to control a real browser using AI for web scraping, competitive intelligence, and UX auditing through the MCP protocol.
Updated 3 months ago (2026-06-24 15:20 UTC)
-
FoxBridge MCP
Browser Automation Web Scraping
sinamohsenifar
A
license
C
quality
B
maintenance
Enables AI assistants to read and drive a real, logged-in Firefox browser, including tabs, cookies, history, and site interactions, all through the Model Context Protocol.
Updated 2 months ago (2026-07-06 17:16 UTC)
52
6 npm
MIT
request-finder
ravi-03
F
license
Not graded
quality
B
maintenance
Enables Claude Code to search and inspect live network traffic from Chrome, including HTTP requests, WebSocket frames, and GraphQL calls, with tools to filter history, retrieve full request details, and control capture settings.
Updated 2 months ago (2026-07-21 05:34 UTC)
-
firefox-use
Web Scraping Testing & QA Tools
leetomo2528
A
license
A
quality
B
maintenance
Browser control for Claude Code, on Firefox.
Updated 8 days ago (2026-09-08 04:20 UTC)
20
MIT