Chrome DevTools MCP vs Playwright MCP for reading pages

Two browser-control servers, one question: which one reads pages for an agent. Chrome DevTools MCP comes from the Chrome DevTools team. Playwright MCP comes from Microsoft. Both drive a real browser. Both read the page through the accessibility tree. They differ on tool count, profile defaults and how they attach to a browser you already run.

All rows below were checked on 2026-11-07 against each project's own docs. These servers ship often. Recount before you rely on a number.

The rubric rows

Sources: Chrome DevTools MCP tool reference, Chrome DevTools MCP configuration, chrome-devtools-mcp README, Playwright MCP README. Checked 2026-11-07.

Tool surface

Chrome DevTools MCP is the larger server. Its tool reference lists 61 tools. The categories go well past page reading: input, navigation, emulation, performance, network, debugging, memory, extensions, WebMCP, Progressive Web Apps and WebAuthn. That is a debugger exposed as tools.

--slim is the counterweight. The configuration docs say it exposes three tools: navigation, script execution and screenshots. Note what slim mode leaves out: the text snapshot. A slim agent reads a page through a screenshot or a script it writes itself.

Playwright MCP starts smaller. 24 core tools cover clicks, forms, navigation, waits, console and network reads, script evaluation and browser_run_code_unsafe. Tab management is one more tool. Vision, PDF and DevTools tools come in only through --caps.

Neither default is small. Every tool definition a client loads takes context before the first page.

Snapshots and page text

Both servers read the accessibility tree, not pixels.

• Chrome DevTools MCP: take_snapshot returns a text snapshot of page elements, each with a uid. Optional filePath and verbose parameters. The tool reference lists no tool that returns page content as Markdown.
• Playwright MCP: browser_snapshot returns the tree. The README calls it better than a screenshot. Responses carry a snapshot by default; --snapshot-mode none turns that off. browser_find returns matching nodes with context.

Both outputs are element trees built for the next click. They are not article text. An agent that only wants the words of a page pays for element roles and identifiers it will never use.

Attaching to your own Chrome

This row is where the two servers differ most.

Chrome DevTools MCP has three ways in. --autoConnect needs Chrome 144 or later, with remote debugging turned on at chrome://inspect/#remote-debugging; Chrome then shows a permission dialog. --browserUrl points at a Chrome started with --remote-debugging-port, for example http://127.0.0.1:9222, and is the documented fallback in sandboxes. --wsEndpoint takes the WebSocket URL instead.

Playwright MCP uses --cdp-endpoint for a CDP endpoint, or --extension for a running Edge or Chrome. The second needs the Playwright Extension installed.

The review note is the same for both. The Chrome configuration docs warn that an attached session gives the agent your logged-in accounts and cookies. The Chrome DevTools MCP README says the server exposes browser content to MCP clients. Two more settings on that side: the README documents a --no-performance-crux flag for the performance tools, and usage statistics are on by default (--no-usage-statistics turns them off). For page reading, attach to nothing. Use --isolated on either server.

Which one, by job

• Debugging a page you build: performance traces, memory, console with source-mapped stack traces. Chrome DevTools MCP.
• Form flows and multi-step navigation in a long session: Playwright MCP. Its README also points coding agents to the Playwright CLI plus skills, and keeps MCP for workflows that need persistent browser state.
• Reading known public pages, such as a changelog or a docs page: neither one is the light pick.

For that last job, a browser-control server is more than you need. A single-page content API is one alternative. Live Web Data API belongs in this group. It returns one public page as clean Markdown, text or HTML through REST or a remote MCP server (Streamable HTTP, bearer key). The MCP server registers 2 tools. Failed fetches cost 0 credits. Its limits, stated plainly: its MCP server does not render JavaScript (browser rendering exists only in the REST API), and it does not crawl sites, run searches or extract structured fields. A page that needs clicks or a script still needs one of the two servers above. The MCP docs describe the server.

Either way, read only public pages, and check robots.txt, the site's terms and your provider's acceptable-use policy first.

More rows: Firecrawl MCP alternatives, sorted by why you are switching and Playwright MCP vs Firecrawl MCP.