Puppeteer MCP: Open pages in a local browser and read the console

Who it's for

For people who need a model to open web pages in a real local browser, read the console, or leave screenshots. The evidence states: this is an MCP server for browser automation with Puppeteer; the model can interact with pages, take screenshots, and run JavaScript in a real browser environment.

It runs on your machine, so it can also reach local files and local/internal IPs. Only connect if you accept that privacy boundary and can keep sensitive data in check. The evidence lists no client names; coverage stops at: you already have a client that can configure MCP and can run npx.

The official page lives under the servers-archived tree. The evidence does not separately state maintenance status or a replacement, so do not treat this as a current product that is still being updated.

First try in 3 minutes

Follow the NPX path given in the evidence. In the client's MCP config use:

"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-puppeteer"]

Do not treat Docker as a second main path at the same time. The evidence only adds: Docker uses headless Chromium; NPX opens a browser window.

Preconditions: Node/npx is installed locally; the first try only opens a public page you may access and will not submit a form or log in. After start, a browser runs on this machine and may access local files and internal addresses.

Where to configure: the client's MCP server config (stdio command and arguments). After saving, restart or reload the client.

Low-risk first call: only call the fully written puppeteer_navigate and navigate to the URL just mentioned. The evidence does not give that tool's parameter fields; the collect summary also mentions screenshot, click, hover, fill, select, evaluate, but those locators are not expanded—do not call them on the first try.

Success signal: on the NPX path you should see a local browser window open and stay on the address you gave. Then you may read the resource console://logs (text console output) or screenshot://<name> (PNG). If no window appears, first confirm you used NPX, not Docker.

Use cases

Case 1: Have the model open a specified public page. Call puppeteer_navigate. The evidence only guarantees “navigate to any URL in the browser”; it does not mention timeouts, redirects, or whether local cookies are sent. What you can confirm: navigation happens in a real local browser; do not assume this is an isolated cloud session.

Case 2: After opening a page, check the console or leave a screenshot. The first evidence item states screenshots and JavaScript execution are possible; the resource evidence gives console://logs (all browser console messages) and screenshot://<name> (PNG of a captured screenshot). The evidence does not name a screenshot tool, how <name> is generated, or evaluate parameters. So the second step only reads these resources, or stops at “the evidence only guarantees screenshots/JS execution”—do not invent selectors or scripts.

Limits

A local browser can access local files and local/internal IPs and may leak sensitive data. NPX opens a visible window; Docker uses headless Chromium. The behaviors differ; do not mix them and then treat a window as the success signal. The only fully named tool in the evidence is puppeteer_navigate; interaction capabilities (click, fill) have no parameterized locator, and running them has page side effects. Resources only list console and screenshots; there is no undo, cookie-clear, or browser-close step. The evidence does not give a client list, a permission model, or a replacement package after archival.