Puppeteer MCP

The score is weighted around the server’s actual job: giving an AI agent reliable browser authority. Basic navigation and interaction still work, but an agent-facing browser server must also be maintainable, compatible with current MCP clients and defensible when it handles untrusted webpages or authenticated sessions.

The server therefore scores reasonably on effectiveness and efficiency, but very poorly on maintainability, compatibility and safety.

@modelcontextprotocol/server-puppeteer is no longer an actively maintained MCP server. Its source was moved into the archived Model Context Protocol reference-server repository, npm marks the package deprecated, and the archive states that archived servers receive no bug fixes, no security updates and no security guarantees.

This lifecycle state matters because Puppeteer MCP is not a passive data reader. It can navigate arbitrary URLs, submit forms, manipulate pages and execute JavaScript inside a browser session.

Puppeteer MCP is an archived Model Context Protocol server that lets an MCP-compatible AI client control a browser through Puppeteer.

The server converts MCP tool calls into Puppeteer browser actions. An agent can navigate to a URL, click or hover over CSS-selected elements, fill inputs, select options, capture screenshots and execute JavaScript in the current page.

The important distinction is that Puppeteer itself remains an active browser-automation project. The deprecated component is this older MCP reference server.

The underlying Puppeteer library is maintained by Chrome’s Browser Automation team. The archived Puppeteer MCP package was a Model Context Protocol reference implementation. They should not be treated as the same project or lifecycle.

The old Puppeteer server primarily works through CSS selectors, screenshots, console output and page JavaScript. That is a simpler interaction model than newer browser-agent servers that return structured semantic page representations.

Typical selectors look like:

button.submit
#email
.product-card:nth-child(2)

This works when the DOM is predictable, but it can be brittle for autonomous agents. A model may need to inspect a page, infer a selector, try an interaction, discover it failed and repeat the loop.

A small tool schema does not guarantee a cheap browser workflow if the model repeatedly guesses selectors and retries actions.

Current Playwright MCP can expose accessibility snapshots and stable element references such as a semantic “Sign in” button. Puppeteer MCP’s older CSS-selector-centric interface gives the model less direct semantic structure. That difference affects both reliability and context efficiency during long agent loops.

The archived package exposes exactly seven browser tools. The small surface is easy for an MCP client to advertise and relatively cheap in schema context.

The package also exposes browser console logs and captured screenshots as MCP resources. This helps observability, but large logs and image-heavy loops can substantially increase context usage.

A simple screenshot task is short:

A form workflow is more expensive because it can require several calls:

navigate → inspect/guess selector → fill → select → click → inspect result → retry if needed

This difference is important when estimating real token usage. Puppeteer MCP’s schema overhead is low, but a brittle interaction loop can generate many turns.

A standard stdio configuration uses:

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

NPX vs Docker

The package includes one useful safeguard: dangerous Chromium launch arguments such as --no-sandbox and --disable-web-security are blocked by default unless dangerous options are explicitly enabled. That is good design, but it does not compensate for the package’s end-of-life status.

Search demand around Puppeteer MCP is strongly client-oriented. The server uses stdio, so clients capable of launching compatible stdio MCP processes can historically configure it. The practical risk is not the configuration syntax—it is compatibility drift as modern MCP clients move beyond the protocol generation used by this package.

The effective authority is broader than the seven-tool count suggests. Depending on the runtime and browser session, Puppeteer MCP can interact with:

• public webpages and browser-rendered content;
• forms, buttons and interactive controls;
• screenshots and browser console output;
• DOM and application state through JavaScript;
• authenticated pages when the browser profile contains a valid session;
• localhost or private-network targets reachable from the host/container.

puppeteer_navigate accepts arbitrary destinations, while puppeteer_evaluate can execute code inside the page. That combination makes network isolation and browser-session hygiene important.

The central security problem is the combination of untrusted webpage content + an LLM decision loop + browser write authority + no active package maintenance.

A 2026 audit of the archived package highlighted unrestricted URL access and the possibility of interacting with local/private-network destinations accessible from the runtime. The old server does not document a modern host allowlist or origin/network policy comparable with newer browser-agent tooling.

puppeteer_evaluate can inspect and manipulate the DOM, form state, page-accessible storage and application state, and can trigger network activity from the page. Puppeteer is designed to make browser automation powerful; exposing that capability to an AI agent makes isolation and review especially important.

A malicious page can contain instructions aimed at the agent. The archived server predates much of the current browser-agent hardening discussion and does not document a modern prompt-injection containment layer.

A May 2026 audit reported that the published 2025.5.12 package resolved @modelcontextprotocol/sdk@1.0.1 and puppeteer@23.11.1. The same review identified high-severity advisories affecting that old MCP SDK line, including ReDoS and missing default DNS-rebinding protection in affected versions.

Because the package is deprecated, there is no expected upstream upgrade path.

The archived release does not adopt MCP 2026-07-28. It was frozen long before that protocol generation existed and still uses @modelcontextprotocol/sdk@1.0.1.

This matters less for a disposable historical test than for a long-lived integration. As clients evolve, a frozen server can continue to launch while gradually losing interoperability with modern protocol expectations.

No separate product-telemetry subsystem was identified in the archived local Puppeteer MCP implementation during the evaluation.

That does not mean browsing is private. The browser still communicates with every website it visits, the MCP client can receive screenshots/console/JavaScript results, and model-provider data handling depends on the client and provider used around the MCP server.

Puppeteer MCP has a useful efficiency advantage at connection time: it exposes only seven tools. Estimated total tool-schema overhead is roughly 2K–4K tokens, depending on the MCP client and the tokenizer/model used.

Tool-schema cost

The seven schemas are small compared with modern browser MCPs exposing dozens of tools. This makes the initial fixed context load relatively low.

Result cost

Normal small text results can be modest. Screenshots, long console logs, base64 image representations and large puppeteer_evaluate results can be much heavier.

Retry cost

The largest hidden context cost can be failed interaction loops. A model may inspect a page, guess a CSS selector, try it, fail, inspect again and repeat. A richer semantic page representation can therefore be more token-efficient in practice even when its tool schemas are larger.

The table uses current standard short-context API rates available on September 27, 2026. It excludes caching, batch discounts, priority/fast tiers, image charges, search/tool fees and subscription plans.

Pricing notes: GPT-5.6 Sol uses its current promotional API rate. Gemini 3.8 Flash uses its introductory 2026 rate. Gemini 3.1 Pro and Grok rows assume a request below their higher long-context price threshold. DeepSeek V4.1 Flash uses its official peak/off-peak pricing range.

The MCP server itself has $0 license cost; it is MIT-licensed. But the meaningful operational cost has four layers.

• browser download and runtime overhead;
• outdated Chrome/Puppeteer compatibility;
• model retries caused by brittle CSS selectors;
• authenticated-session exposure;
• local/private-network reachability;
• webpage prompt injection;
• no future security patches;
• eventual client breakage from old MCP protocol support.

The biggest hidden cost is building workflows around software whose upstream project explicitly does not intend to maintain it.

Archived and unsupported

The central limitation. There is no normal upstream path for fixes, SDK upgrades, browser-compatibility work or security remediation.

Small tool surface

Seven tools keep the schema lean, but modern browser MCPs expose much richer navigation, structured page state, network and debugging capabilities.

CSS-selector-oriented targeting

Agents can struggle when they must infer brittle selectors instead of receiving stable semantic element references.

Screenshot and retry overhead

Image-heavy workflows and repeated selector attempts can consume more context than the small schema count suggests.

Limited debugging depth

Console logs provide some observability, but there is no equivalent of the dedicated network, performance and DevTools surface now available through Chrome DevTools MCP.

No maintenance response

New browser-agent threats, protocol changes and dependency issues cannot be assumed to receive an upstream patch.

Google search evidence connects these two servers strongly enough that the comparison belongs on the parent page, but the full query deserves its own dedicated comparison URL.

Puppeteer itself has not disappeared from MCP browser automation. Its current documentation now points MCP users to Chrome DevTools MCP, a maintained Puppeteer-based server for browser automation and debugging.

That creates a clearer present-day relationship:

Chrome DevTools MCP adds deeper browser diagnostics such as network inspection, console debugging, screenshots and performance-oriented tooling. For someone specifically seeking a maintained Puppeteer-backed MCP, this is the important successor relationship to understand.

If you specifically need to investigate the historical server, use a disposable environment rather than a normal personal browser session.

1. Run the server in a disposable container or isolated machine.
2. Do not attach authenticated personal browser data.
3. Block access to sensitive private networks.
4. Navigate a public test page.
5. Capture a screenshot.
6. Test click, fill and select behavior.
7. Execute a harmless JavaScript inspection.
8. Try a page containing prompt-injection-style text.
9. Compare the same task with Chrome DevTools MCP and Playwright MCP.

This measures whether the historical server still works in your environment without turning the test itself into an unnecessary security exposure.

Puppeteer MCP was useful as an early demonstration of browser automation through MCP. The toolset is small, understandable and inexpensive at schema-load time. It also includes a sensible default that blocks obviously dangerous Chromium launch flags unless explicitly enabled.

But this exact server has reached end-of-life. It is archived with no security guarantees, npm marks it deprecated, it remains on an old MCP SDK, and Puppeteer’s current documentation now points MCP users toward Chrome DevTools MCP instead.

Browser MCPs operate on untrusted webpages while retaining click, form and JavaScript authority. In that environment, maintenance is a first-order safety property—not a cosmetic project-health metric.

Verdict confidence: Low. The package’s archive and deprecation status are strongly evidenced. Confidence is lower for present-day performance because an abandoned server naturally has little fresh 2026 user and release evidence.

The evaluation therefore separates strong lifecycle evidence from measurements that would still require a controlled live run.

• Chrome launch reliability on current operating systems;
• current website compatibility;
• click/form success rate;
• exact token usage under a chosen client/model;
• browser crash frequency;
• current client interoperability.

Those measurements could change the performance picture. They would not change the documented fact that the upstream package is deprecated and archived.