Puppeteer

The Puppeteer MCP server wraps Google's Puppeteer library behind the Model Context Protocol, giving any MCP-compatible AI agent the ability to navigate pages, take screenshots, click elements, fill forms, and run arbitrary JavaScript, all inside a real Chrome instance on your machine.

Every serious AI agent eventually needs to browse the web. Not just fetch HTML, but actually load a page the way a browser does, click through login flows, wait for JavaScript to finish rendering, take a screenshot for vision models, and extract data that only appears after interaction. The Puppeteer MCP server covers all of that in seven tool calls.

What is the Puppeteer MCP server

The Puppeteer MCP server is a reference implementation from the Model Context Protocol team at Anthropic. It wraps Puppeteer, the JavaScript library that drives Chrome through the Chrome DevTools Protocol, and exposes it as a set of MCP tools any compatible client can call.

The core idea is straightforward: instead of writing browser automation scripts yourself, you let the AI agent decide when and how to use the browser. The agent navigates a page, takes a screenshot if it needs visual context, fills a form, clicks submit, and reads the result, all through standard tool calls that arrive back as text or base64 images.

You can browse the full list of available MCP servers to see how the Puppeteer server fits into the broader ecosystem.

The seven tools

The server exposes exactly seven tools:

• puppeteer_navigate - loads any URL, with optional Puppeteer launch options for things like ignoring HTTPS errors or setting a user agent
• puppeteer_screenshot - captures the full page or a specific CSS selector; returns a base64 PNG the agent can feed to a vision model
• puppeteer_click - clicks an element by CSS selector
• puppeteer_hover - hovers over an element, useful for triggering dropdown menus and tooltips
• puppeteer_fill - types into an input field
• puppeteer_select - changes the value of a SELECT element
• puppeteer_evaluate - runs arbitrary JavaScript in the page context and returns the result

This surface is intentionally minimal. You get navigation, interaction, vision, and scripting. That covers the vast majority of real-world browser automation tasks an agent would encounter.

Installation

The fastest path is npx. Add this block to your Claude Desktop or Claude Code MCP config file:

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

Restart your client. The next time the agent calls puppeteer_navigate, a Chrome window opens and you can watch it work in real time. That visible browser is one of the better debugging experiences in the MCP ecosystem.

For headless execution on a server or in CI, the Docker config runs a Chromium instance with no display required:

{
  "mcpServers": {
    "puppeteer": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "--init", "-e", "DOCKER_CONTAINER=true", "mcp/puppeteer"]
    }
  }
}

No API keys, no accounts, no monthly bill. The browser runs locally and the data stays on your machine.

Where it fits in an agent workflow

The typical use case is a research or data-extraction agent. You give the agent a goal like "find the pricing page for each tool in this list and extract the cheapest plan." The agent navigates each URL, takes a screenshot if the page is complex, evaluates some JavaScript to pull structured data, and builds a result. The whole loop runs without any human clicking.

The puppeteer_evaluate tool deserves special attention because it turns the browser into a general-purpose scraper. The agent can write arbitrary JavaScript to extract DOM content, parse JSON embedded in script tags, or trigger client-side events that no CSS selector can reach. Combined with puppeteer_screenshot feeding a vision model, you can handle pages that are essentially unscrapable by traditional means.

For agents that already do a lot of code-related work, like Claude Code, browser control becomes useful for testing web UIs, verifying deployment results, or extracting information from documentation sites.

The archived status problem

Here is the honest part. The Puppeteer MCP server was archived in May 2025 and moved to the modelcontextprotocol/servers-archived repository. It still installs and runs fine today, but it will not receive bug fixes, protocol updates, or new tools. If the MCP spec changes in a way that breaks the server, nobody will patch it.

For greenfield projects starting now, Microsoft's Playwright MCP server is the more pragmatic choice. It is actively maintained, exposes a richer interaction model, and handles the growing complexity of modern web apps better. The Playwright library itself also supports Firefox and WebKit alongside Chromium, which matters for cross-browser testing.

That said, the Puppeteer MCP server is not broken. If you already use it in a working pipeline or you just want the quickest path to "AI agent that can browse," it still delivers. The archived status matters more if you are building something production-critical that needs to track MCP spec updates over time.

Compare it to Browser Use, which takes a different approach entirely: it is a framework that builds its own browser automation layer with agent-friendly abstractions on top, rather than wrapping an existing library through MCP. Browser Use has more built-in intelligence around element selection and action planning, while Puppeteer MCP is lower-level and gives the AI model direct control over each action.

Practical limitations

A few things to know before you commit to Puppeteer MCP for a project:

The server keeps one browser session open at a time. If you need parallel browsing across multiple tabs or windows, you are working against the design. Each navigate call lands in the same page context unless you manage tabs through puppeteer_evaluate manually.

Sites with strong bot detection will flag headless Chromium. Passing the DOCKER_CONTAINER=true environment variable enables the headless mode, which is easier to fingerprint than the headed npx version. Real user-agent spoofing and stealth plugins are outside the server's scope.

There is no built-in wait strategy beyond what Puppeteer's default navigation wait provides. For pages that load content after complex async operations, you may need puppeteer_evaluate to poll for elements or add explicit delays.

Who should use it

If you are building an agent for AI-driven coding tasks and want to add quick web access, the Puppeteer MCP server is a reasonable choice. The setup is under five minutes and the tool surface is easy for a model to reason about.

If you are building a production scraping pipeline or an agent that needs reliable browser automation over months, look at the Playwright MCP server or Browser Use instead. The archived status of Puppeteer MCP is not a dealbreaker today, but it will become one the longer you depend on it without a migration plan.

Summary

The Puppeteer MCP server solves a real problem: it gives any AI agent a working browser without cloud subscriptions or complex infrastructure. Seven tools, one Chrome instance, runs locally. The main caveat is that it has been archived since May 2025, so it is not the future-proof choice for serious production use. For quick experiments, internal tools, and agents that need basic web access today, it remains one of the fastest ways to get started.

Features

• Navigate to any URL with custom launch options
• Full-page or element-scoped screenshots
• Click, hover, and fill interactions
• SELECT element handling
• JavaScript evaluation in the browser context
• Console log capture
• Headless (Docker) or headed (npx) execution modes

How to set up the Puppeteer MCP server

1. Add the server to your Claude Desktop or Claude Code MCP config using the npx command below
2. Restart your client; a Chrome window will open on first navigate call
3. Optionally switch to the Docker config for headless execution in CI or servers