Safari 27 gives coding agents a local MCP path into live browser debugging

WebKit added an MCP server to Safari 27 beta and Safari Technology Preview 247. The server runs through `safaridriver --mcp` and can be connected to any Model Context Protocol-compatible client. Once remote automation and external agents are enabled, a coding agent can inspect and control a live Safari browser window through tools for DOM/page content, console messages, network requests, screenshots, JavaScript evaluation, navigation, tab management, viewport/media emulation and page interactions.

Coding agents are increasingly able to edit code, but browser-specific failures still require runtime evidence. Safari’s MCP server gives agents first-party access to the browser engine that production users actually run, reducing the gap between generating a fix and observing its effect in Safari. It also turns browser state into a new trust boundary: the server itself stays local, but page content, screenshots and console data can be passed to the connected agent or model, so authenticated sessions and sensitive development environments need deliberate isolation.

The new server is built into Safari’s automation path rather than shipped as a separate third-party bridge. WebKit documents tools for reading page content and console logs, inspecting individual and aggregate network requests, evaluating JavaScript, capturing screenshots, controlling tabs and navigation, performing DOM interactions and emulating viewport or media settings. That gives an agent enough runtime context to investigate layout, JavaScript, network and accessibility-style failures directly in Safari.

WebKit provides setup examples for Claude and Codex but says any MCP-compatible client can use the server. Developers enable Web Developer features plus remote automation and external agents, then register `/usr/bin/safaridriver --mcp` for Safari 27 beta or the corresponding Safari Technology Preview binary. The browser therefore becomes another tool server in an existing agent workflow rather than requiring an Apple-specific assistant.

WebKit says the Safari MCP server runs entirely on the local machine and makes no network calls of its own. It also says the server cannot access personal Safari information such as AutoFill or unrelated browser activity. However, when it captures page content, screenshots or console logs, that material goes directly to the connected agent rather than Apple. What happens after that depends on the agent and model, so developers should not interpret local server execution as meaning browser data necessarily stays local.

Safari is not alone: Chrome DevTools for agents also exposes live browser inspection and control to MCP-compatible coding tools. The implementations differ, but the direction is similar—browser vendors are turning debugging primitives into machine-callable interfaces. That can make cross-browser agent testing more practical while also making browser-session permissions, authenticated state and reproducibility part of agent-tool governance.