What is the difference between Safari MCP, Chrome DevTools MCP and Playwright MCP?

All three let a coding agent such as Claude Code or Codex see and drive a real browser over the Model Context Protocol. Safari MCP, new in Safari 27.0 (September 2026), is Apple's built-in server: it runs from /usr/bin/safaridriver --mcp, exposes the DOM, network, console, screenshots, computed styles, accessibility checks and navigation timing, and is the only way to test WebKit on macOS with an agent. Chrome DevTools MCP (v1.9.0, September 8, 2026) is Google's server with 26 tools across input, navigation, debugging, network, performance and emulation, including full performance traces. Playwright MCP is Microsoft's server with 70+ tools built on accessibility snapshots, running Chromium, Firefox and WebKit headless or headed, and is the best fit for repeatable flows and test generation.

Which browser MCP server is best for debugging?

Chrome DevTools MCP. It is the only one that exposes Chrome's performance tracing, CPU and network throttling emulation and full DevTools network inspection to the agent. Safari MCP covers the same debugging basics for WebKit (console, network requests, computed styles, navigation timing) but has no equivalent of a DevTools trace. Playwright MCP is strong on deterministic actions and console/network capture but is not a profiler.

Can I use Safari MCP with Claude Code and Codex?

Yes. Enable Safari > Settings > Developer > 'Allow remote automation and external agents', then run `claude mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp` or `codex mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp`. Any other MCP client works with a mcp.json entry whose command is /usr/bin/safaridriver and args are ["--mcp"]. It requires Safari 27.0 on macOS; the server is local-only, makes no network calls of its own and sends captured data to your agent, not to Apple.

Should I install more than one browser MCP server?

Often, yes — but not all at once. Each server adds 26–70 tool definitions to the agent's context, which costs tokens on every turn. A practical setup is Chrome DevTools MCP as the default for building and debugging, Playwright MCP enabled for test-writing sessions, and Safari MCP switched on when you need to verify WebKit rendering or iOS-style behaviour. Keep agents in a separate browser profile with no banking or admin logins.

Quick Answer

Safari MCP vs Chrome DevTools MCP vs Playwright MCP (2026)

Published: September 19, 2026

The three servers at a glance

	Safari MCP	Chrome DevTools MCP	Playwright MCP
Maintainer	Apple (WebKit team)	Google (Chrome DevTools team)	Microsoft (Playwright team)
Current version	Safari 27.0 (September 2026)	v1.9.0 (September 8, 2026)	Tracks Playwright (1.63 line)
Engines	WebKit only	Chrome / Chromium only	Chromium, Firefox, WebKit
Tool count	Not enumerated publicly; DOM, network, console, screenshots, styles, a11y, perf timing	26 tools in 6 categories	70+ tools (core + opt-in capabilities)
Performance profiling	Navigation timing, resource load times	Full performance traces, CPU/network throttling	No profiler
Headless	No (drives a Safari window)	Yes or headed	Yes or headed
Platforms	macOS only	macOS, Windows, Linux	macOS, Windows, Linux
Install	Built in: `/usr/bin/safaridriver --mcp`	`npx chrome-devtools-mcp@latest`	`npx @playwright/mcp@latest`
Price	Free	Free, open source	Free, open source
Best for	Verifying WebKit/iOS behaviour on a Mac	Debugging and performance work in Chrome	Repeatable flows, test generation, cross-engine checks

Verified September 19, 2026 against Apple’s WebKit blog, the Chrome DevTools MCP GitHub releases and Playwright’s MCP documentation.

Safari MCP — the new one

Safari 27.0 shipped the Safari MCP server in September 2026, and Apple’s pitch is aimed squarely at coding agents: “Give Claude Code, Codex, or the agent of your choice control over the browser window so it can see how your code renders.” The server lets an agent:

see how a page renders in Safari and take screenshots;
verify user state in forms, checkout flows and selections;
compare computed styles and layout with other browsers;
test accessibility — missing labels, bad ARIA, poor contrast;
read navigation timing and resource load times.

Three design points matter. It runs entirely on your machine and makes no network calls of its own. It has no access to your personal Safari data — it uses WebDriver-style isolated automation windows. And captured data goes to your agent, not Apple. Setup is one toggle plus one command (see the Safari MCP setup guide).

Choose it when: the bug only reproduces in Safari, you ship to iOS users, or you want an agent to check WebKit before a release. Skip it when: you need headless CI, Windows/Linux, or profiling deeper than timing APIs.

Chrome DevTools MCP — the debugger

Google’s server, at v1.9.0 as of September 8, 2026, exposes 26 tools grouped into input automation, navigation, debugging, network, performance and emulation. The standout is performance tracing: the agent can start a trace, load a page, stop, and reason over the results — nothing else on this list can do that. It also emulates slow CPU and network, lists console messages and network requests, evaluates JavaScript and resizes the viewport. The repository has passed 50,000 GitHub stars by third-party counts.

Choose it when: the job is “why is this slow” or “what is the network doing”, or when your users are overwhelmingly on Chrome. Skip it when: you need Firefox or WebKit coverage, or a deterministic test artefact at the end.

Playwright MCP — the automator

Microsoft’s server drives Playwright’s engine over MCP and works from accessibility snapshots rather than screenshots, which keeps agent context small and actions deterministic. It has more than 70 tools: navigation, forms, clicking and typing, console and network capture in the always-on core, plus opt-in capabilities for vision, PDF, DevTools, network mocking, storage and tracing. It runs Chromium, Firefox and WebKit, headless or headed, and preserves login state, cookies and local storage by default.

Choose it when: you want the agent to walk a flow, prove it works repeatedly, and leave a Playwright test behind; or you need one server across three engines. Skip it when: you need profiling, or a real Safari rather than Playwright’s WebKit build (they differ in ways that matter for iOS-specific bugs).

Head-to-head on what developers actually ask

“Can the agent see my page?” All three: screenshots and DOM. Playwright’s accessibility snapshots are the cheapest in tokens; Chrome DevTools and Safari give richer style and layout data.

“Can it tell me why the page is slow?” Chrome DevTools MCP, clearly. Safari gives timing numbers; Playwright gives none.

“Can it test on the browsers my users have?” Playwright covers the most engines from one server. Only Safari MCP tests real Safari. Chrome DevTools tests only Chrome.

“Can it run in CI?” Playwright and Chrome DevTools, yes (headless). Safari MCP is a desktop tool.

“Is it safe with my logged-in sessions?” Safari MCP is the most conservative by design (isolated automation windows, no personal data). Chrome DevTools MCP and Playwright MCP can attach to a profile with your sessions — keep agents in a separate profile without banking, admin or password-manager logins, because prompt injection from web content against a session-holding agent remains unsolved in 2026.

A sensible default stack

Daily driver: Chrome DevTools MCP for build-and-debug loops.
Test sessions: enable Playwright MCP when you want a test file at the end.
Pre-release: switch on Safari MCP on a Mac to check WebKit rendering and forms.

Do not leave all three enabled in every session — you would be paying for roughly a hundred tool definitions on every turn.