Puppeteer MCP: understand the tools and configure browser access

Puppeteer is a browser automation library. MCP is a protocol that lets a client call a server’s tools. A search for “Puppeteer MCP” can refer to different packages; check the exact project, permissions and maintenance status before copying a configuration.

The old reference Puppeteer MCP server is in the archived MCP servers repository. That does not mean Puppeteer itself is archived.

An inline configuration example

Chrome DevTools MCP is a Google/Chrome DevTools project that uses Puppeteer. It gives an MCP client access to Chrome tools. It does not provide Firefox automation.

For an MCP client that supports an mcpServers configuration object, the relevant structure is:

{
    "mcpServers": {
        "chrome-devtools": {
            "command": "npx",
            "args": [
                "--yes",
                "chrome-devtools-mcp",
                "--isolated",
                "--slim",
                "--no-usage-statistics",
                "--no-performance-crux",
                "--allowed-url-pattern=https://example.com/*"
            ]
        }
    }
}

The client must have Node/npm on its subprocess PATH. npx runs the selected package; it is not a download from this website. Use the exact configuration location/shape documented by your client. Replace the example destination only with a URL you are authorized to inspect.

The URL allowlist requires a compatible Chrome build. --isolated uses a temporary profile, and --slim exposes fewer tools. Neither creates an OS sandbox; the host must still provide suitable isolation.

Give the client a bounded task

A useful first task is: “Open the allowed example.com page, report its heading and stop.” Do not start with account actions or an unrestricted personal browsing session. If the client needs an output directory, constrain it using the server’s documented filesystem options and the host’s own permissions.

Navigation, page JavaScript evaluation and screenshots still carry authority. Treat page text as data, not instructions to send credentials, install packages or access internal services. Require appropriate approval for meaningful side effects.

Privacy and isolation

Usage statistics and CrUX URL transmission are separate settings. Disabling one does not disable every possible browser/network behavior. Do not attach an untrusted client to a logged-in browser, expose a debugging endpoint publicly or allow arbitrary filesystem paths.

A URL pattern is not a complete SSRF/network security boundary. Review redirects, subresources and actual egress policy before processing untrusted input. Keep Chrome patched and its sandbox enabled; isolated profiles reduce session-state leakage, not exploit risk by themselves.

Diagnose failures without widening permission

Check the actual client subprocess logs, Node/server/browser pairing, allowed origin and server options. Inspect structured MCP error results as well as text; blocked navigation need not include a useful human-readable message.

Do not remove an allowlist just to suppress an authorization failure. Use an approved destination or explicitly revise the task boundary. Stop owned client/server processes when finished.

For browser automation directly in Node.js, use the Puppeteer tutorial. See screenshots for capture and waiting for application results.