Safari ships an MCP server: local server, not a local pipeline

published Sep 18, 2026

#safari#mcp#privacy#devtools

TL;DR

Safari now exposes an MCP server through safaridriver, so Claude Code, Codex or any MCP client can drive a real Safari window — read the DOM, click things, inspect network requests, take screenshots. WebKit says the server “runs entirely on your local machine and makes no network calls of its own.” That is true and it is narrower than it sounds: local describes the server, not the pipeline. Everything the server captures is handed to your agent, and your agent ships it to a model provider. Setup is one command plus two checkboxes, and the first checkbox is the one people miss.

What shipped

The Safari MCP server first appeared in Safari 27 beta and Safari Technology Preview 247, announced on 2026-07-01. It reached stable with macOS 27, which released on September 14, 2026, and WebKit’s Safari 27.0 features post on 2026-09-17 put it back in front of everyone.

There is no separate binary to install. It runs on safaridriver, the WebDriver executable already bundled with Safari. That is the genuinely nice part of the design: the automation surface Safari already had gets an MCP front door, and a coding agent can reach live DOM, console output, network request detail, computed styles and screenshots through it.

It is macOS-only. If you are on Linux or Windows, this post is not for you.

Setup, and the checkbox that hides the other checkbox

Two settings must be enabled, in this order, and the first one is what makes the second one visible:

Safari > Settings > Advanced — check Show features for web developers.
Safari > Settings > Developer — check Allow remote automation and external agents.

Most of the coverage quotes only step 2, which is exactly the step you cannot find if you skipped step 1, because the Developer tab is not there yet.

Then register the server with your agent:

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

Codex takes the same shape with codex substituted; other clients point an mcp.json entry at the same binary and flag.

What the tools cover

WebKit’s post lists the tools in a table. I am deliberately not giving you a count — I read that page twice and the prose disagreed with itself about the number both times, while the list of names stayed identical. Recount it yourself if the figure matters to you.

What the names tell you is that the set is scoped to the debugging loop rather than to general automation:

Area	Tools
Navigation	`navigate_to_url`, `wait_for_navigation`, `page_info`
Tabs	`list_tabs`, `create_tab`, `switch_tab`, `close_tab`
Reading the page	`get_page_content`, `screenshot`, `evaluate_javascript`
Network	`list_network_requests`, `get_network_request`
Console and dialogs	`browser_console_messages`, `browser_dialogs`
Interaction	`page_interactions`
Environment	`set_viewport_size`, `set_emulated_media`

set_emulated_media is the one worth noticing: it is how an agent checks your dark-mode and print styles without you toggling anything, and it is the kind of tedious verification pass that is worth handing off.

What is not here: no profiling timeline, no coverage tooling, no direct access to the Web Inspector’s own panels. This drives a browser and reads what it sees.

Where the privacy line actually sits

This is the part worth being precise about, because “runs locally” is doing a lot of work in the coverage.

WebKit’s own sentence: “The Safari MCP server runs entirely on your local machine and makes no network calls of its own.” That is a statement about the server process. The same post continues: when it captures page content, screenshots or console logs, “that data goes directly to the agent you’re running — not to Apple.”

Read those together and the boundary is clear. Apple is not in the loop. Your model provider is — because the agent’s whole job is to send what it reads to a model. A get_page_content call on a page behind your company SSO puts that page’s DOM in a prompt. A screenshot of a staging dashboard uploads that screenshot. list_network_requests can surface tokens in request headers.

WebKit says the quiet part itself, and it is the last line of that section: “As with any agent you give access to your browser, only use ones you trust.”

That is not a reason to avoid this. It is a reason to know which tab is in front when you let an agent look.

Practical rules

Drive a dedicated profile or window. The tools operate on real tabs, including whatever you were logged into.
Treat get_page_content and screenshot as uploads, because that is what they are once the agent has them.
Prefer evaluate_javascript returning a narrow value over dumping a whole page when you only need one computed style or one element’s state.
Remember the toggle is persistent. “Allow remote automation and external agents” stays checked after you are done. Uncheck it when you are not using it.

Caveats

macOS-only, and tied to Safari 27 / macOS 27 or Safari Technology Preview.
The tool count in the WebKit post is unreliable as published; the names are the trustworthy part.
I have not tested behaviour against Private Browsing windows, and WebKit’s post does not address it — assume nothing until you check.
Nothing here is unique to Safari as a risk. A Chrome DevTools MCP server has the same shape. Safari is just the one that shipped this week with a privacy sentence people are reading more generously than it was written.