Most MCP servers connect agents to APIs — structured data in, structured data out. The Puppeteer MCP server is different. It gives an AI agent control of a real Chromium browser. Navigate to a URL, click buttons, fill forms, take screenshots, run JavaScript. The agent sees and interacts with the web the way a human does.

This is one of the official reference servers maintained in the modelcontextprotocol/servers repository. It’s been around since the early days of MCP (November 2024), and it remains one of the most popular MCP servers — ranked in the top 50 globally. Here’s what it’s actually like to work with.

What It Does

The server provides seven tools that cover core browser interactions:

  • puppeteer_navigate — Navigate to a URL. This is your starting point for any browser session.
  • puppeteer_screenshot — Take a screenshot of the current page or a specific element. Returns the image so the agent (if it has vision capabilities) can see what’s on screen.
  • puppeteer_click — Click an element using a CSS selector. Buttons, links, checkboxes — anything clickable.
  • puppeteer_fill — Type text into an input field. For forms, search boxes, login fields.
  • puppeteer_select — Choose an option from a <select> dropdown.
  • puppeteer_hover — Hover over an element. Useful for tooltips and menus that appear on hover.
  • puppeteer_evaluate — Execute arbitrary JavaScript in the browser console. The escape hatch for anything the other tools don’t cover.

The server also captures browser console logs, so the agent can see JavaScript errors and debug output. Screenshots are stored as resources that can be retrieved later in the conversation.

Setup

Installation is straightforward. The fastest path:

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

Add that to your Claude Desktop config (or equivalent MCP client config) and you’re running. The server downloads Puppeteer’s bundled Chromium on first launch — expect a brief wait the first time.

Docker option: If you prefer containers, there’s a Docker setup available. This is useful for CI/CD pipelines or environments where you don’t want npm installing a browser binary directly.

Environment variables give you some control over browser behavior:

  • PUPPETEER_HEADLESS=false — Run in visible mode so you can watch what the agent does. Great for debugging and demos.
  • PUPPETEER_SLOWMO=250 — Add delays between actions for slow-motion playback.
  • PUPPETEER_TIMEOUT=60000 — Extend timeouts for slow-loading pages.

Setup difficulty: Easy. One npx command in your config. No API keys, no OAuth, no accounts. This is one of the simplest MCP servers to get running.

What Works Well

Screenshots make agents genuinely useful for web tasks. An agent that can see a webpage — not just read its HTML — can answer questions like “does this page look broken?” or “what does the checkout flow look like?” With a vision-capable model, the screenshot tool turns your agent into a pair of eyes on the web. This is transformative for debugging, QA, and visual verification tasks.

JavaScript evaluation is incredibly flexible. The puppeteer_evaluate tool is an escape hatch that covers almost anything. Need to extract structured data from a page? Run a querySelector. Need to scroll to trigger lazy loading? Execute window.scrollTo(). Need to check a computed style or read localStorage? All doable. When the other six tools aren’t enough, this one fills the gap.

Zero-config is real. No API keys. No accounts. No OAuth dance. No token management. Add the config block, restart your client, and you have a browser. After reviewing servers that require GitHub tokens, Slack OAuth, or Brave API keys, the simplicity here is refreshing.

Console log capture aids debugging. When something goes wrong on a page — a JavaScript error, a failed network request — the agent can see it in the console logs. This makes the Puppeteer server useful for web development tasks beyond just browsing: checking for errors, verifying scripts loaded correctly, monitoring API calls.

Stateful sessions work naturally. The browser persists across tool calls within a session. Navigate to a login page, fill credentials, click submit — the agent stays logged in for subsequent requests. This makes multi-step workflows possible without re-authenticating at each step.

What Doesn’t Work Well

CSS selectors are brittle. Every interaction tool (click, fill, select, hover) targets elements via CSS selectors. The agent has to figure out the right selector for a button or input field, and that requires either inspecting the page source or taking a screenshot and guessing. If the page uses dynamic class names (common with React, Next.js, and CSS-in-JS frameworks), selectors break across page loads. This is the single biggest friction point.

No accessibility tree access. This is the key advantage that Microsoft’s Playwright MCP server has over Puppeteer MCP. Playwright uses the browser’s accessibility tree to identify elements — structured, semantic labels like “Submit button” or “Email input” instead of brittle CSS selectors like .btn-primary-2x. For complex, dynamic web apps, this makes Playwright substantially more reliable for element targeting.

Chrome/Chromium only. Puppeteer doesn’t support Firefox or Safari. If you need to test cross-browser behavior or interact with a site that renders differently in WebKit, you’re out of luck. Playwright supports all three browser engines.

Browser startup adds latency. Launching a Chromium instance takes a few seconds. For quick, one-off queries this overhead is noticeable. The browser stays running across a session, so subsequent tool calls are fast — but that first navigation has a cold-start penalty.

Resource consumption is real. A headless Chromium process uses 200-500MB of RAM depending on the pages loaded. On a development machine, this is fine. On a constrained server or shared environment, it adds up — especially if multiple agents are running browser sessions simultaneously.

No built-in file download or upload handling. You can navigate to a download link and click it, but managing where the file goes and confirming the download completed requires custom JavaScript. Similarly, file upload inputs need workaround scripts. These are common automation needs that the tool set doesn’t directly address.

Anti-bot detection can block you. Many websites use bot detection (Cloudflare, reCAPTCHA, fingerprinting) that flags headless Chromium. The default Puppeteer setup doesn’t include stealth plugins. If you’re trying to interact with sites that actively block automation, you’ll hit walls. There are community stealth solutions, but they require additional configuration.

Compared to Alternatives

vs. Playwright MCP Server (@playwright/mcp): The most direct competitor and, for many use cases, the better choice in 2026. Playwright MCP uses accessibility tree snapshots instead of CSS selectors, supports Chrome, Firefox, and WebKit, and is now the default browser automation recommendation from Claude Code, Cursor, and VS Code Copilot. Puppeteer has a slightly simpler setup and deeper Chrome DevTools integration, but Playwright’s element targeting is more reliable for complex apps. If you’re starting fresh, try Playwright first.

vs. Browserbase MCP Server: Browserbase is a cloud-hosted browser service — you get a managed browser without running Chromium locally. Better for production workloads and environments where local browser installation isn’t practical. Puppeteer MCP is better for development and local experimentation where you want direct control.

vs. Firecrawl MCP Server: Firecrawl focuses specifically on web scraping — extracting clean content from pages. If you just need to read web content, Firecrawl is more targeted. Puppeteer is for when you need to interact with pages: click, fill, navigate multi-step flows. Different tools for different jobs.

vs. puppeteer_evaluate for everything: Some users skip the click/fill/select tools entirely and just use puppeteer_evaluate with JavaScript to do everything. This works but defeats the purpose of having structured tools — it’s harder for the agent to reason about, harder to debug, and more error-prone. Use the dedicated tools when they fit; fall back to evaluate when they don’t.

Who Should Use This

Yes, use it if:

  • You want your agent to visually verify web pages (screenshots + vision model)
  • You need to automate multi-step browser workflows (login, fill forms, extract data)
  • You’re debugging or testing web applications and want an agent that can see the page
  • You want the simplest possible browser MCP setup — no API keys, no accounts
  • You’re already in the Puppeteer/Chrome DevTools ecosystem

Consider Playwright MCP instead if:

  • You’re working with complex, dynamic web apps where CSS selectors are unreliable
  • You need cross-browser support (Firefox, Safari/WebKit)
  • You’re using Claude Code, Cursor, or VS Code Copilot (they recommend Playwright)
  • Accessibility-tree-based element targeting matters to your workflow

Skip browser MCP entirely if:

  • You just need to read web page content (use Firecrawl or a fetch-based server)
  • You’re working on a server with no GUI and limited RAM
  • Your target sites aggressively block automated browsers
3.5 / 5 — Capable but showing its age
The Puppeteer MCP server does what it promises: it gives your agent a real browser. Screenshots, navigation, form filling, JavaScript execution — the core tools work and the zero-config setup is genuinely effortless. But in 2026, with Playwright MCP offering accessibility-tree targeting, cross-browser support, and growing ecosystem adoption, Puppeteer MCP feels like the older option. The CSS selector dependency is a real liability for complex web apps, and the Chrome-only limitation matters more than it used to. If you need quick browser access and you’re already in the Puppeteer ecosystem, it’s still a solid tool. But for new projects, Playwright MCP is the stronger starting point. Puppeteer MCP earns its place as the approachable, no-fuss browser server — just know that a more capable alternative exists.