Skip to main content
Glama
dijdzv

wsl-chrome-mcp-bridge

by dijdzv
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

wsl-chrome-mcp-bridge

MCP bridge that launches Chrome on Windows from WSL2 and proxies chrome-devtools-mcp.

How it works

Claude Code (WSL2)
    ↕ stdio (JSON-RPC)
wsl-chrome-mcp-bridge (WSL2)
    ├── spawns Chrome on Windows (--remote-debugging-port)
    ├── spawns chrome-devtools-mcp via npx
    └── proxies MCP messages + adds chrome_open / chrome_close tools

The bridge adds two lifecycle tools (chrome_open / chrome_close) and proxies all other tool calls to chrome-devtools-mcp. Chrome is launched on-demand when chrome_open is called and tool definitions are prefetched at startup for instant availability.

Related MCP server: BrowserPilot MCP

Requirements

  • WSL2 with mirrored networking mode enabled (see below)

  • Node.js >= 20

  • Google Chrome installed on Windows

  • npx available in PATH

WSL2 mirrored networking

The bridge connects to Chrome's debug port at 127.0.0.1. WSL2's default NAT mode isolates the network from Windows, so mirrored mode is required.

Add to %USERPROFILE%\.wslconfig:

[wsl2]
networkingMode=mirrored

Then restart WSL: wsl --shutdown

Installation

# Run directly (no install needed)
npx -y wsl-chrome-mcp-bridge

# Or install globally
npm install -g wsl-chrome-mcp-bridge

Claude Code configuration

Add to your .mcp.json:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "wsl-chrome-mcp-bridge"]
    }
  }
}

Options

Option

Environment Variable

Default

Description

--port, -p

CHROME_DEBUG_PORT

9222

Chrome remote debugging port

--user-data-dir

CHROME_USER_DATA_DIR

C:\tmp\chrome-devtools-mcp

Chrome user data directory (Windows path)

--chrome-path

CHROME_PATH

auto-detect

Path to Chrome executable

--headless

CHROME_HEADLESS=1

off

Run Chrome in headless mode

--help, -h

Show help

--version, -v

Show version

Chrome path auto-detection

  1. Query Windows registry via PowerShell (App Paths\chrome.exe)

  2. Check known paths (/mnt/c/Program Files/Google/Chrome/Application/chrome.exe, etc.)

License

MIT

Available Tools

2 tools
chrome_closeA

Close the Chrome debugging instance and disconnect DevTools MCP.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/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 full responsibility for behavioral disclosure. It states the action (close and disconnect) but does not explain side effects, such as whether unsaved data is lost, if the operation is reversible, or if a connection must already exist. The lack of detail reduces 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?

The description is a single clear sentence that conveys the essential purpose without any extraneous words. It is well front-loaded and efficiently uses the limited space.

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?

Given that there are no annotations and no output schema, the description is minimally adequate for a simple destroy-type tool. However, it could benefit from mentioning preconditions (e.g., must have an active debugging instance) or confirming that it does not affect other Chrome windows.

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 no parameters, and the input schema is empty with 100% coverage. The description adds no parameter information, which is acceptable since none is needed. Baseline for zero parameters is 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 clearly states the tool's action: closing the Chrome debugging instance and disconnecting DevTools MCP. It distinguishes from the sibling 'chrome_open', which presumably opens a Chrome debugging instance, making the purpose unambiguous.

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 guidance is provided on when to use this tool versus alternatives. The only sibling is 'chrome_open', and it is implied that close should be used after opening is complete, but no when-not-to-use or prerequisites are mentioned.

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

chrome_openA

Launch Chrome with remote debugging and connect DevTools MCP. Call this before using any other Chrome DevTools tools.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/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 it launches Chrome and connects debugging, but doesn't mention side effects like opening a window, process lifetime, or idempotency. Adequate but could be more detailed.

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 efficient sentences with no wasted words. Front-loaded with the primary action and followed by usage guidance.

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 simplicity (no parameters, no output schema), the description covers the tool's purpose and prerequisite role. Could mention behavior on repeated calls, but overall complete enough.

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%. The description naturally adds no parameter info, but baseline is 4 per rules. No issues.

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 launches Chrome with remote debugging and connects DevTools MCP, and specifies it's a prerequisite for other tools. This is specific and distinguishes it from the sibling tool chrome_close.

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?

Explicitly says 'Call this before using any other Chrome DevTools tools,' which is clear guidance on when to use it. No alternatives or when-not guidance are needed for a setup tool.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

The two tools, chrome_open and chrome_close, are completely distinct actions with no overlap. Each serves a single clear purpose.

Naming Consistency5/5

Both tools follow the consistent pattern 'chrome_<verb>', using snake_case and clear verb_noun structure.

Tool Count5/5

With exactly two tools for opening and closing the bridge, the count is minimal but perfectly scoped for the server's intended role.

Completeness5/5

The tool set fully covers the lifecycle of the Chrome debugging instance (start and stop), with no necessary operations missing for this narrow domain.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dijdzv/wsl-chrome-mcp-bridge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server