CloakBrowser MCP: Playwright MCP tools with a CloakBrowser Chromium runtime

Dmitry Vasiliev — Sat, 06 Jun 2026 16:50:17 +0000

Updated October 22, 2026: requirements and examples below target CloakBrowser MCP 1.15.1.

Browser automation is becoming one of the most useful tool categories for AI agents.

If an agent can open a page, inspect the accessibility tree, click buttons, fill forms, read console output, and take screenshots, it can help with tasks that are hard to solve through APIs alone: debugging frontend flows, checking documentation, testing onboarding, validating generated UI, and reproducing browser-only bugs.

Playwright MCP is already a strong foundation for that workflow. It gives MCP clients a browser automation surface built around Playwright. The question that led to CloakBrowser MCP was narrower:

What if you want the same upstream Playwright MCP tools, but with a different Chromium runtime?

That is what cloakbrowser-mcp does.

What is CloakBrowser MCP?

cloakbrowser-mcp is an open-source Model Context Protocol server that runs upstream @playwright/mcp with the CloakBrowser Chromium executable.

The project is intentionally thin:

upstream Playwright MCP owns the browser tool schemas, descriptions, and responses
cloakbrowser-mcp generates a Playwright MCP config that points launchOptions.executablePath to CloakBrowser
upstream browser tools are forwarded unchanged
the bridge adds only two local diagnostic tools

Those local tools are:

cloakbrowser_binary_info
cloakbrowser_bridge_info

Everything else comes from upstream Playwright MCP.

Repository:

https://github.com/swimmwatch/cloakbrowser-mcp

Docs:

https://swimmwatch.github.io/cloakbrowser-mcp/

npm:

https://www.npmjs.com/package/cloakbrowser-mcp

What it is not

This is not a custom browser automation API.

It is not a fork that rewrites Playwright MCP tool contracts.

It is not a CAPTCHA-solving service, and it should not be treated as a replacement for proper test-environment controls, allowlists, or site-owner-approved automation paths.

The goal is narrower and more maintainable: keep the Playwright MCP surface familiar, while letting users run that surface with CloakBrowser Chromium in local or Docker-backed agent workflows.

Why preserve the upstream Playwright MCP contract?

Browser MCP servers can become painful when every server invents a slightly different tool surface.

If the tool names, schemas, and behavior drift, users have to relearn the same browser workflow for each runtime. Clients and prompts also become less portable.

cloakbrowser-mcp takes the opposite approach. The bridge stays small and lets upstream Playwright MCP remain authoritative for browser tools.

That matters for a few reasons:

Existing Playwright MCP workflows stay familiar.
Upstream improvements can be adopted without redesigning a parallel tool model.
The bridge can focus on runtime wiring, diagnostics, packaging, and parity checks.
Users can compare behavior against upstream Playwright MCP more easily.

The project also runs parity checks against upstream default tools in CI, so changes to the forwarded tool surface are visible during development.

Quick start with npm

Requires Node.js 22.13.0 or newer in the 22.x line, or Node.js 24 or newer (^22.13.0 || >=24.0.0).

npx -y cloakbrowser-mcp@1.15.1 --help
npx -y cloakbrowser-mcp@1.15.1 doctor
npx -y cloakbrowser-mcp@1.15.1

Use doctor first if you want a local diagnostic check before wiring the server into an MCP client:

npx -y cloakbrowser-mcp@1.15.1 doctor --json

The default transport is stdio, which is what most local MCP client configs expect.

For Streamable HTTP:

npx -y cloakbrowser-mcp@1.15.1 \
  --transport streamable-http \
  --http-port 3000

That exposes MCP at:

http://127.0.0.1:3000/mcp

It also provides health probes:

curl http://127.0.0.1:3000/healthz
curl http://127.0.0.1:3000/readyz

MCP client config

Most MCP clients use the same stdio shape: command, args, and optional env.

{
  "mcpServers": {
    "cloakbrowser": {
      "command": "npx",
      "args": ["-y", "cloakbrowser-mcp@1.15.1"],
      "env": {
        "PLAYWRIGHT_MCP_HEADLESS": "true",
        "PLAYWRIGHT_MCP_OUTPUT_DIR": "/tmp/cloakbrowser-artifacts"
      }
    }
  }
}

The example above uses the mcpServers format supported by clients such as Claude Desktop and Cursor. VS Code uses a servers object with "type": "stdio"; Codex uses TOML. Follow the client-specific setup instructions instead of copying the same configuration into every client.

Docker

Docker is useful when you want a repeatable runtime. The image is based on the pinned official Playwright MCP image and includes the bridge.

docker pull swimmwatch/cloakbrowser-mcp:1.15.1
docker run --rm --init -i \
  -v "$PWD/artifacts:/data" \
  swimmwatch/cloakbrowser-mcp:1.15.1

For Streamable HTTP in Docker:

docker run --rm --init -p 127.0.0.1:3000:3000 \
  -v "$PWD/artifacts:/data" \
  swimmwatch/cloakbrowser-mcp:1.15.1 \
  --transport streamable-http \
  --http-host 0.0.0.0 \
  --http-port 3000

The same images are also published to GitHub Container Registry:

ghcr.io/swimmwatch/cloakbrowser-mcp

What tools should appear?

Ask your MCP client to list tools. You should see upstream Playwright MCP browser tools, such as:

browser_navigate
browser_click
browser_type
browser_snapshot
browser_take_screenshot
browser_console_messages
browser_network_requests
browser_evaluate
browser_tabs

You should also see the two local diagnostic tools:

cloakbrowser_binary_info
cloakbrowser_bridge_info

The diagnostic tools are there to answer practical setup questions:

Which bridge version is running?
Which upstream Playwright MCP package/version is resolved?
Which browser engine is configured?
Where is the CloakBrowser binary?
Which output directory is active?

Configuration

The primary configuration namespace is the upstream Playwright MCP namespace:

PLAYWRIGHT_MCP_*

For Cloak-specific bridge toggles:

CLOAK_PLAYWRIGHT_MCP_*

Common examples:

PLAYWRIGHT_MCP_HEADLESS=true
PLAYWRIGHT_MCP_OUTPUT_DIR=/tmp/cloakbrowser-artifacts
PLAYWRIGHT_MCP_OUTPUT_MODE=stdout
CLOAK_PLAYWRIGHT_MCP_CONSOLE_FALLBACK=true
CLOAK_PLAYWRIGHT_MCP_STEALTH_ARGS=true

For local HTTP transport:

CLOAK_PLAYWRIGHT_MCP_TRANSPORT=streamable-http
CLOAK_PLAYWRIGHT_MCP_HTTP_HOST=127.0.0.1
CLOAK_PLAYWRIGHT_MCP_HTTP_PORT=3000
CLOAK_PLAYWRIGHT_MCP_HTTP_ENDPOINT=/mcp

For external or non-loopback access, use HTTPS plus an auth token, or a trusted reverse proxy that enforces TLS, authentication, and network access controls. The bridge auth token can be configured with:

CLOAK_PLAYWRIGHT_MCP_HTTP_AUTH_TOKEN=...

Operational notes

A few details are worth knowing before using it in a real workflow:

The first browser action may download the CloakBrowser binary if it is not already cached.
In stdio mode, stdout is reserved for MCP protocol messages. Streamable HTTP mode may write startup and request logs to stdout.
Docker runs should keep -i so stdio stays connected.
Docker runs should include --init so browser child processes are reaped correctly.
Artifacts should be written to a known output directory, especially in Docker.
For reproducibility, pin a version instead of using latest.

Example:

npx -y cloakbrowser-mcp@1.15.1

Or:

docker run --rm --init -i \
  -v "$PWD/artifacts:/data" \
  swimmwatch/cloakbrowser-mcp:1.15.1

When should you use it?

It is a good fit when you want:

Playwright MCP-compatible browser tools
a local stdio MCP server
a Docker-ready browser automation runtime
Streamable HTTP for clients that connect over HTTP
a CloakBrowser Chromium runtime without changing upstream Playwright MCP tool contracts
simple diagnostics before wiring the server into an agent

It is probably not the right fit if:

you need a hosted browser service
you want a custom high-level browser API instead of Playwright MCP tools
your workflow should use official APIs instead of browser automation
your testing environment can solve the problem with first-party test keys or allowlists

Try it

The fastest path is:

npx -y cloakbrowser-mcp@1.15.1 doctor

Then add the stdio config to your MCP client:

{
  "mcpServers": {
    "cloakbrowser": {
      "command": "npx",
      "args": ["-y", "cloakbrowser-mcp@1.15.1"]
    }
  }
}

Project links:

GitHub: https://github.com/swimmwatch/cloakbrowser-mcp
Docs: https://swimmwatch.github.io/cloakbrowser-mcp/
npm: https://www.npmjs.com/package/cloakbrowser-mcp
Docker Hub: https://hub.docker.com/r/swimmwatch/cloakbrowser-mcp
MCP Registry: https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.swimmwatch%2Fcloakbrowser-mcp

Feedback is welcome, especially from people already using Playwright MCP in local agent workflows.

DEV Community: Dmitry Vasiliev