Safari 27 ships a built-in MCP server. The browser is now an agent endpoint.

Safari 27.0 shipped on September 14, 2026, and with it came a native Model Context Protocol server built into the browser. Apple's WebKit team documented it in a post titled "Introducing the Safari MCP server for web developers." Any MCP-compatible client can connect to a live Safari window through the browser's own safaridriver binary.

This is the first browser to ship an MCP server bundled with the browser itself. That needs one qualification. Google has shipped an official Chrome DevTools MCP server since 2025, but it arrives as a separate npm package the agent launches itself (npx chrome-devtools-mcp), not as part of Chrome. Safari's is the first where the browser is the endpoint out of the box.

What it exposes

Nineteen tools, per the WebKit post. They split into two groups.

Correction (2026-09-27): We miscounted. Apple's tool table lists 17 tools, not 19: browser_console_messages, browser_dialogs, close_tab, create_tab, evaluate_javascript, get_network_request, get_page_content, list_network_requests, list_tabs, navigate_to_url, page_info, page_interactions, screenshot, set_emulated_media, set_viewport_size, switch_tab, wait_for_navigation. The "Nineteen tools" sentence above, the "19" in this article's dek, and the "tool list is fixed at 19" line in the closing section are all superseded by this count. Nothing else in the article changes.

Observation tools: screenshot capture as PNG, page content extraction in markdown, HTML or JSON, console log access, individual and batched network request detail (headers, bodies, timing), page info with URL, title and load state, and tab listing.

Action tools: JavaScript execution with return values, DOM interactions in sequence (click, type, scroll, hover, keyPress), navigation with load-state tracking, tab create, switch and close, dialog handling (accept, dismiss, text input), viewport sizing in CSS pixels, and CSS media type emulation for responsive testing.

The intended workflow is debugging with a coding agent. The post's framing example: a bug report comes in about a page in Safari, the agent inspects the live render, and the developer stops pasting screenshots into a terminal. Apple's listed use cases include verifying checkout flows and form states, comparing computed styles against other browsers, accessibility checks for missing labels and poor contrast, and performance analysis through navigation timing.

How to enable it

Two Settings toggles, both off by default. First, Safari > Settings > Advanced > "Show features for web developers." That unlocks a Developer pane. Then Safari > Settings > Developer > "Allow remote automation and external agents."

Connection for Claude Code is one command:

claude mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp

Codex gets the same shape (codex mcp add safari-mcp -- "/usr/bin/safaridriver" --mcp). Any other MCP client takes a standard config block with command /usr/bin/safaridriver and args ["--mcp"]. Per Apple, the agent does not need to be told explicitly to use it; it picks the server up on its own.

The security posture, and its limit

Apple's claims, stated as Apple's claims: the server runs entirely on the local machine, makes no network calls of its own, and has no access to personal Safari data such as AutoFill or other browser activity. Captured content goes directly to the connected agent, not to Apple. Then the honest sentence: "What happens to that data from there depends on the agent and model you're using." Apple's own advice is blunt: only give browser access to agents you trust.

That trust warning matters more than the local-only claim. An agent with the server enabled sees everything in the tab: page content, cookies in network captures, authenticated sessions, internal staging environments. The toggle is per-browser, not per-site, and nothing in the documentation describes per-tab or per-origin scoping. Enabling it on a browser logged into production systems hands the agent the keys to whatever you are looking at.

Compare the posture to Google's. The Chrome DevTools MCP repo's own disclaimers warn that it "exposes content of the browser instance to the MCP clients" and notes that Google collects usage statistics by default, with an opt-out flag. Safari's post makes no telemetry claim either way. Neither server is a sandbox. Treat both as full read-write access to the tab.

Should you adopt it

Adopt it if your automation target is Safari and your workflow is development debugging on macOS. The friction is near zero for anyone already running Claude Code or Codex: two toggles, one command, no third-party package to maintain. It replaces the worst of the status quo for this specific job, the manual screenshot-and-prompt loop.

Do not treat it as a replacement for Playwright-style automation. It is a debugging and inspection surface, not a test runner. There is no assertion framework, no cross-browser matrix, no headless CI story in the announcement. The tool list is fixed at 19, and it is scoped to a live Safari window you already have open. If your pipeline needs deterministic, headless, multi-browser runs, keep your existing stack and add this as a developer-loop tool.

The deeper significance is the pattern. Google and now Apple have both decided the browser should speak MCP natively. Google ships it as a package; Apple ships it with the browser. The endpoint you thought of as a window is becoming an API.

What remains unknown

Everything below is documentation-based. We did not install Safari 27 or connect an agent, so real-world reliability, tool behavior at the edges, and performance are untested. Apple documents only the macOS safaridriver path; nothing here claims support on iOS, iPadOS or visionOS builds of Safari 27.

We also do not know whether enterprise device management will lock the "Allow remote automation and external agents" toggle, whether Apple will expand the tool list, or how the Safari server behaves with multiple agents connected at once. And the competitive question is open: whether Chrome follows Apple and bundles its server into the browser, which would make the browser-as-endpoint pattern the default rather than the experiment.