BrowserTools MCP logo

BrowserTools MCP

OrganizationPopular
AgentDeskAI

Monitor browser logs directly from Cursor and other MCP compatible IDEs.

PublisherAgentDeskAI
Repositorybrowser-tools-mcp
LanguageTypeScript
Forks
534
Stars
7.3K
Available tools
16
Transport typestdio
Categories
LicenseMIT
Links
  • Connect tools to AI workflows

    BrowserTools MCP exposes MCP capabilities that can be used by compatible AI clients and agents.

  • 16 available tools

    Browse the callable actions below, including names and descriptions when provided by the server.

  • Ready-to-copy setup

    Use the installation snippets to configure this server in your preferred MCP client.

  • Open source signals

    7.3K stars and 534 forks from the linked repository.

BrowserTools MCP

Give your AI coding agent eyes on the browser. BrowserTools MCP streams console output, network activity, screenshots and Lighthouse audits from your real Chrome session — the one already logged into your app — to any MCP-compatible client: Cursor, Claude Code, Windsurf, Cline, Zed, Gemini CLI, and others.

Version 2.0 is a rewrite. One process instead of three, no unauthenticated local server, credentials scrubbed before they leave the browser, and a real test suite. If you are coming from 1.x, read MIGRATION.md — and upgrade, because 1.2.x has a critical vulnerability. See SECURITY.md.


Why this instead of a CDP-based server

Tools like Chrome DevTools MCP and Playwright MCP drive a fresh, automated browser. That is the right choice for writing tests. It is the wrong choice for debugging the app you are actually looking at, because since Chrome 136 the browser refuses remote debugging on your default profile — the one holding your logins. So you end up recreating your auth state in a throwaway profile before you can debug anything.

BrowserTools attaches to the session you are already in, through a DevTools extension. You stay logged in, on the page you were already on, and your agent reads what you see. It also reports Lighthouse-grade performance, accessibility and SEO data, which the automation-first servers do not.

Install

Two pieces: an MCP server (one command) and a Chrome extension.

1. Point your MCP client at the server

json
{
  "mcpServers": {
    "browser-tools": {
      "command": "npx",
      "args": ["-y", "@agentdeskai/browser-tools-mcp@latest"]
    }
  }
}

On Windows, if your client cannot find npx, use "command": "cmd" with "args": ["/c", "npx", "-y", "@agentdeskai/browser-tools-mcp@latest"].

Requires Node 22.19 or newer. Check with node --version; if you use nvm or asdf, make sure your editor inherits the same version.

2. Load the Chrome extension

  1. Download or clone this repository.
  2. Open chrome://extensions and turn on Developer mode.
  3. Choose Load unpacked and select the chrome-extension directory.

That is the whole setup. There is no second server to start — the MCP server runs the connector itself.

3. Use it

Open Chrome DevTools (F12) on the page you want to inspect. Capture begins as soon as DevTools is open; the BrowserTools panel is only for settings and status. Then ask your agent something like "check the console for errors" or "run an accessibility audit on this page".

Not working? Run npx @agentdeskai/browser-tools-mcp --doctor, which reports exactly which piece is missing.

To watch capture happen live — useful when checking a fresh install — start the connector with --verbose:

npx @agentdeskai/browser-tools-server --verbose
· console error tab 42 Uncaught TypeError: total is not a function
· network 500 POST tab 42 https://myapp.local/api/pay (1310ms)

Without it the connector only reports connect and disconnect, so a working setup and a silent one look the same.

Tools

ToolWhat it does
getConsoleLogsConsole output, filterable by keyword with paging
getConsoleErrorsError-level output and uncaught exceptions
getNetworkLogsXHR/fetch requests with status, timing and bodies
getNetworkErrorsOnly failed and 4xx/5xx requests
getSelectedElementThe element selected in the Elements panel
getPageInfoWhich page the browser is currently on
getConnectionStatusWhether the extension is connected, and capture counts
listBrowserTabsEvery tab with DevTools open, and the id to address it by
takeScreenshotScreenshot returned as an image, plus its file path
refreshBrowserReloads the inspected tab
getBrowserStoragelocalStorage, sessionStorage and cookies (values gated)
wipeLogsClears captured telemetry before a clean reproduction
runAccessibilityAuditLighthouse accessibility audit
runPerformanceAuditLighthouse performance audit with Core Web Vitals
runSEOAuditLighthouse SEO audit
runBestPracticesAuditLighthouse best-practices audit

Three prompts ship alongside them — debuggerMode, auditMode and nextjsSeoAudit — giving your agent a systematic workflow instead of a wall of static text in every tool listing.

All tools declare MCP output schemas, so clients receive structured data rather than prose they have to parse, and read-only tools are annotated as such so clients can auto-approve them safely.

Several tabs at once

Every tab with DevTools open is tracked separately. Telemetry is attributed to the tab that produced it, and retention is per tab, so a chatty page cannot push out the history of the one you care about.

Tools act on the current tab — the one you most recently opened DevTools on. A tab whose connection drops and comes back does not steal that position, which is what used to make screenshots capture the wrong page. Every result reports the tabId and url it came from, plus otherTabs, so a wrong-tab answer is visible rather than silent. To target a specific tab, call listBrowserTabs and pass its tabId to any tool; pass allTabs: true to read across every tab.

Large data stays out of the context window

Whole-history payloads are exposed as MCP resources rather than inlined, and tools link to them with resource_link so your agent fetches them only when it decides to:

ResourceWhat it is
browser-tools://console/{tabId|all}Every console entry, with no per-call budget
browser-tools://network/{tabId|all}Every captured request, including bodies
browser-tools://har/{tabId|all}The same traffic as a HAR 1.2 file
browser-tools://screenshot/{name}A screenshot you captured earlier
browser-tools://audit/{reportId}The unabridged Lighthouse result behind a summary

Log tools attach a link when a read had to be cut short; network reads always offer the HAR; screenshots always link to the stored image, which is the only way to see one too large to inline. The last 20 full Lighthouse reports are kept under audits/ in the screenshot directory.

Keeping responses small

Log payloads are the usual cause of a blown context window. Every read tool takes limit and offset, and the log tools take keyword filters:

getConsoleErrors({ keywords: ["hydration"], limit: 20 })
getNetworkLogs({ urlKeywords: ["/api/"], bodyKeywords: ["quota"], limit: 10 })

Results are returned newest-first and always report total alongside returned, so an agent knows when it is only seeing part of the picture.

Privacy and security

This tool captures whatever your browser sees, so it treats that data carefully:

  • Loopback only. The connector binds 127.0.0.1 and refuses non-loopback addresses. In 1.x it bound 0.0.0.0, reachable by anyone on your network.
  • The extension never leaves loopback. 1.x scanned private network ranges and adopted whichever host answered with a known string — meaning anyone on shared Wi-Fi could receive your logs and screenshots. That scan is gone.
  • Authenticated. The HTTP API requires a per-run token. The WebSocket accepts browser-extension origins only, so a web page you visit cannot impersonate the extension.
  • Credentials are scrubbed on the way in: Authorization, Cookie and similar headers, plus JWTs, cloud keys and vendor tokens found anywhere in captured strings, become [REDACTED].
  • Headers are off by default, per direction, and storage values are withheld unless explicitly requested.
  • Cookie access is an optional permission you grant from the panel, not something the extension holds by default.

Report vulnerabilities per SECURITY.md.

Configuration

Flags, or the matching BROWSER_TOOLS_* environment variables:

FlagPurpose
--port <n>Connector port (default 3025)
--screenshot-dir <path>Where screenshots are written
--only <a,b>Expose only these tools
--exclude <a,b>Hide these tools
--doctorCheck the setup and exit
--verbosePrint each captured entry as it arrives
--host <addr>Loopback address to bind (default 127.0.0.1)
--connect <url>Attach to a connector already running elsewhere
--token <t>Auth token to use with --connect
--no-redactDisable credential scrubbing (not recommended)

To share one browser session between several MCP clients, start the connector once with npx @agentdeskai/browser-tools-server and every client will attach to it automatically.

Known limits

  • Network capture starts when DevTools opens. Requests that finished before then are not recorded — reload the page to capture a full page load.
  • Screenshots are held to a byte budget (screenshotMaxBytes, 3 MB by default). A capture that would exceed it is re-encoded as JPEG and, if still too large, downscaled. A viewport capture of dense content on a high-DPI display can otherwise run past 13 MB, which is more than a model's context can take and past the read buffer newer MCP stdio transports enforce. If an image still cannot fit, it is written to disk and the tool returns the path instead of inlining it.
  • Console capture defaults to the DevTools protocol, which makes Chrome show a "started debugging this browser" banner. Switch the panel's capture mode to Wrap page console to avoid it.
  • Firefox is not verified. The extension is written cross-browser — a browser/chrome shim, browser_specific_settings, and a capture mode that does not need chrome.debugger — but it has never been loaded in Firefox, and nothing in the test suite covers it. Screenshots in particular go through the DevTools protocol and will not work there. Treat Firefox as unsupported until someone has actually run it; a report either way is welcome.
  • Audits launch a separate browser and take up to a minute. Any Chromium-based browser works — Chrome, Chromium, Brave, Edge, Vivaldi, Opera or Arc — and --doctor reports which one will be used. Set CHROME_PATH to override. Arc is supported on a best-effort basis and has not been verified headless.

Development

bash
npm install
npm run build
npm test           # unit + integration, no browser required
npm run test:e2e   # real Chromium with the extension loaded

npm test runs in seconds. The end-to-end suite launches a headed Chromium with the extension installed, drives fixture pages, and asserts the whole capture path — run npx playwright install chromium first.

License

MIT

Installation

TypingMind
{
  "mcpServers": {
    "browser-tools-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@agentdeskai/browser-tools-mcp@latest"
      ]
    }
  }
}

Available Tools

  • listBrowserTabs

    Every browser tab that currently has DevTools open, with the tabId you can pass to any other tool. Call this when a result reported otherTabs above 0, or when the user mentions a page other than the one you have been reading. The tab marked isCurrent is the one every other tool uses when you do not pass tabId.

  • getConsoleLogs

    Console output from the current tab. Use keywords and limit to keep responses small — an unfiltered read can be large. Pass tabId for a different tab, or allTabs to read every tab; the result reports which tab it came from.

  • getConsoleErrors

    Only error-level console output and uncaught exceptions from the current tab. Start here when diagnosing a failure. Pass tabId for a different tab, or allTabs to read every tab.

  • getNetworkLogs

    XHR and fetch requests from the current tab, including status and timing. Credential headers are redacted. Pass tabId for a different tab, or allTabs to read every tab.

  • getNetworkErrors

    Only requests that failed or returned a 4xx/5xx status. An empty result means there were no failures, which is a success, not an error.

  • getSelectedElement

    The DOM element the user has selected in the Chrome DevTools Elements panel, with its attributes and markup.

  • getPageInfo

    Which page the browser is currently on. Call this before reading telemetry so you know what the logs describe. If connectedTabs is above 1, call listBrowserTabs before assuming this is the page the user means.

  • getConnectionStatus

    Whether the Chrome extension is connected and how much telemetry has been captured. Call this first when something returns nothing.

  • takeScreenshot

    Captures the visible area of the current tab and returns the image directly, plus the path it was saved to and the url captured. Pass tabId to capture a different tab.

  • refreshBrowser

    Reloads the inspected tab. Useful for capturing a clean reproduction after calling wipeLogs.

  • getBrowserStorage

    Lists localStorage, sessionStorage and cookie entries for the current page. Values are withheld unless includeValues is set, because they routinely contain session tokens.

  • wipeLogs

    Discards captured console and network entries for every tab, or one tab if you name it. Use before reproducing a problem so the next read contains only relevant output.

  • runAccessibilityAudit

    Lighthouse accessibility audit of the current page: contrast, labels, semantics and screen-reader support. Takes up to a minute and launches a separate headless browser.

  • runPerformanceAudit

    Lighthouse performance audit of the current page, including Core Web Vitals. Takes up to a minute and launches a separate headless browser.

  • runSEOAudit

    Lighthouse SEO audit of the current page: metadata, indexability and crawlability. Takes up to a minute and launches a separate headless browser.

  • runBestPracticesAudit

    Lighthouse best-practices audit of the current page: security, deprecated APIs and modern-web hygiene. Takes up to a minute and launches a separate headless browser.

Use BrowserTools MCP MCP with multiple AI models

TypingMind connects MCP tools at the workspace level, so once BrowserTools MCP is connected, you can use it with different AI models in TypingMind instead of setting it up separately for each model. This MCP runs locally through the TypingMind MCP connector on your device.

Setup guide to use the local connector

Use this when the MCP server needs access to local files, apps, or private resources on your computer.

1

Open the MCP settings

In TypingMind, go to Settings, Advanced Settings, then Model Context Protocol and choose Setup Connector.

  1. Open TypingMind in your browser.
  2. Click the Settings icon.
  3. Go to Advanced Settings.
  4. Open the Model Context Protocol section.
  5. Click Setup Connector and choose This Device.
TypingMind MCP connector setup screen with This Device selected
2

Run the connector command

Choose This Device, copy the command from TypingMind, and run it in Terminal. Keep the process running while you use MCP.

  1. Copy the setup command shown by TypingMind.
  2. Open Terminal on macOS or Windows Terminal on Windows.
  3. Paste and run the command.
  4. Approve the package install if Terminal asks you to proceed.
  5. Keep the Terminal window running while using MCP tools.
3

Add BrowserTools MCP as a server

When the connector status is Ready, click Edit Servers and paste the MCP server configuration.

  1. Wait until the connector status shows Ready.
  2. Click Edit Servers.
  3. Paste the BrowserTools MCP MCP server configuration.
  4. Save the server list.
  5. Refresh if you want to confirm the connector is still ready.
TypingMind MCP settings showing active server and Edit Servers button
{
  "mcpServers": {
    "browser-tools-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "browser-tools-mcp-workspace"
      ]
    }
  }
}
4

Use it across models

Save the server list, open Plugins, enable the BrowserTools MCP MCP tools, then select any supported AI model in TypingMind and use the tools in chat or assign them to an AI agent.

  1. Open the Plugins page in TypingMind.
  2. Enable the BrowserTools MCP MCP tools.
  3. Start a chat and choose the AI model you want to use.
  4. Use the MCP tools in chat or assign them to an AI agent.
  5. Switch to another AI model whenever needed without reconnecting MCP.
TypingMind chat using enabled MCP tools with a selected AI model
Can you use BrowserTools MCP to help me with this task?
BrowserTools MCP
Sure. I read it.
Here is what I found using BrowserTools MCP.

Frequently asked questions

What is the BrowserTools MCP MCP server used for?

BrowserTools MCP is an MCP server that lets compatible AI clients connect to external tools and context. In TypingMind, you can add this MCP server once and make its tools available in your AI workspace.

Can I use BrowserTools MCP MCP with multiple AI models in TypingMind?

Yes. TypingMind connects MCP tools at the workspace level, so you can use BrowserTools MCP with different AI models such as Claude, ChatGPT, Gemini, or other models you have configured in TypingMind without setting up the MCP server separately for each model.

Why use BrowserTools MCP MCP with TypingMind?

TypingMind is one of the best frontends for LLM chat because it brings multiple AI models, prompts, plugins, AI agents, API keys, and MCP tools into one workspace. With BrowserTools MCP connected, you can use its MCP tools across your preferred models while keeping your chat workflow organized in TypingMind.

How do I connect BrowserTools MCP MCP to TypingMind?

BrowserTools MCP runs through the TypingMind local MCP connector. This is best when the MCP server needs access to local files, desktop apps, command-line tools, or private resources on your computer.

What tools does BrowserTools MCP MCP provide in TypingMind?

BrowserTools MCP exposes 16 MCP tools that can be enabled from the TypingMind Plugins page and used in chat or assigned to AI agents.

Do I need to share my API keys with TypingMind to use BrowserTools MCP MCP?

No. TypingMind is local-first and lets you keep your model providers, API keys, prompts, and MCP configuration under your control. If BrowserTools MCP requires authentication, add the required headers, OAuth settings, or local configuration for that MCP server when you create the connection.

debuggerMode

A systematic workflow for diagnosing a problem on the live page using console and network telemetry.

auditMode

A workflow for running and interpreting accessibility, performance, SEO and best-practices audits.

nextjsSeoAudit

SEO review tailored to Next.js applications, combining a live SEO audit with framework-specific causes.

Related MCP Servers

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇