writing/blog/2026/07
BlogJul 4, 2026·6 min read

Safari MCP Server: Let AI Agents Debug the Web

Apple's new Safari MCP server lets AI coding agents inspect the DOM, run JavaScript, and debug pages in Safari Technology Preview. Full setup guide inside.

On July 3, 2026, the WebKit team announced something few developers expected from Apple: an official Safari MCP server, shipping in Safari Technology Preview 247. With one command, your AI coding agent — Claude Code, Codex, or any MCP-compatible client — can now connect to a live Safari window, inspect the DOM, read console logs, monitor network requests, take screenshots, and interact with pages autonomously.

This is Apple's second first-party MCP server in a month, following the Xcode MCP server unveiled around WWDC 2026. The message is clear: agentic tooling is no longer a community hack. It is becoming a standard layer of the platform itself.

What Is the Safari MCP Server?

The Safari MCP server is a Model Context Protocol server built directly into safaridriver, the WebDriver binary that ships with Safari Technology Preview. Instead of speaking the WebDriver protocol to a test runner, it speaks MCP to an AI agent.

The practical problem it solves is one every web developer knows: your agent writes CSS or JavaScript, you switch to the browser, reload, check the console, screenshot the glitch, paste it back into the chat, and repeat. The Safari MCP server removes that loop entirely. The agent sees how the code actually renders — in WebKit, not just in Chromium.

That last point matters more than it sounds. Agents could already drive Chrome through the Chrome DevTools MCP server or browser automation frameworks like Browser Use and Stagehand. Safari — the engine behind every browser on iOS and a large share of mobile traffic in the MENA region — was the blind spot. WebKit-specific rendering quirks, flexbox edge cases, and Safari-only bugs were invisible to autonomous debugging workflows. Not anymore.

The 16 Tools Agents Get

The server exposes 16 tools, covering four broad areas:

Inspection and rendering

  • browser_console_messages — retrieves buffered console logs
  • page_info — returns URL, title, and loading state
  • get_page_content — extracts page content as markdown, HTML, or JSON
  • screenshot — captures PNG screenshots of the current viewport

Network monitoring

  • list_network_requests — summarizes all network activity
  • get_network_request — returns detailed data for a specific request

Interaction and navigation

  • navigate_to_url, wait_for_navigation — load pages and wait for completion
  • page_interactions — click, type, scroll, and hover on DOM elements
  • evaluate_javascript — executes arbitrary JavaScript in the page
  • create_tab, close_tab, switch_tab, list_tabs — full tab management
  • browser_dialogs — accepts or dismisses browser dialogs

Emulation

  • set_viewport_size — resizes the viewport for responsive testing
  • set_emulated_media — switches CSS media types and features (print, dark mode, reduced motion)

Together these cover the core of what a human does in Web Inspector during a debugging session — which is exactly the point.

Setting It Up

Requirements

  • macOS with Safari Technology Preview 247 or later (free download from Apple's developer site)
  • An MCP-compatible agent such as Claude Code or Codex

Step 1 — Enable developer features in Safari Technology Preview

  1. Open Settings → Advanced and enable "Show features for web developers"
  2. Open Settings → Developer and enable "Enable remote automation and external agents"

Step 2 — Register the server with your agent

For Claude Code:

claude mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

For Codex:

codex mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp

For any other MCP client, add this to your mcp.json or equivalent configuration:

{
  "mcpServers": {
    "safari-mcp-stp": {
      "command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver",
      "args": ["--mcp"]
    }
  }
}

That is the entire setup. No npm package, no Docker container, no API key — the server is the browser.

What You Can Ask Your Agent to Do

Once connected, the agent decides on its own when to reach for the browser. Apple's announcement suggests starter prompts like:

  • "Find bugs on my site in Safari" — the agent navigates, reads console errors, inspects failing network requests, and correlates them with your source code.
  • "How accessible is my site in Safari?" — it queries the DOM for missing labels, broken ARIA attributes, and contrast problems, then proposes concrete fixes.
  • "See how my website performs in Safari" — it pulls navigation timing and resource load metrics straight from the page.
  • "Check my checkout flow at 390px wide" — it resizes the viewport, fills the form, clicks through, and screenshots every step.

The workflow shift is subtle but profound: instead of you being the bridge between the agent and the browser, the agent closes the loop itself — write code, render, observe, fix, repeat. This is the same agentic coding loop pattern that has reshaped backend development, now extended to visual, WebKit-accurate frontend work.

Security and Privacy Considerations

Apple designed the server to run entirely on your machine. The server itself initiates no outbound network traffic, and personal Safari data — AutoFill credentials, browsing history — stays inaccessible to connected agents.

But there is an important boundary to understand: screenshots, console logs, and page content are sent to whatever agent you connect, and from there to that agent's model provider. Apple never sees the data, but your LLM vendor does. The WebKit team's guidance is blunt: only connect agents you trust.

The usual MCP hygiene applies. A browser-controlling agent that reads page content is exposed to whatever those pages contain, including prompt injection attempts embedded in web content. Treat a Safari-connected agent session like a browsing session with elevated automation powers: keep it pointed at your own sites and staging environments, not at arbitrary untrusted pages with your production credentials loaded.

The Bigger Picture: MCP Becomes Platform Infrastructure

The most interesting part of this release is not the tool list — it is who shipped it. Platform vendors are no longer waiting for the community to build MCP bridges:

  • Apple now ships MCP servers for both Xcode and Safari
  • JetBrains ships first-party MCP support in IntelliJ, Rider, and PyCharm
  • VS Code has native MCP support
  • GitHub Copilot routes tool calls through MCP

One observer summed it up well: this is the S3 moment for agent tooling. Just as S3-compatible endpoints became the default interface for storage regardless of backend, MCP is becoming the default interface for agent-to-tool communication — a trend we analyzed in our MCP vs CLI comparison. When the browser vendor, the IDE vendor, and the code host all speak the same protocol, the question is no longer whether agents will have access to your tools. It is whether your own product exposes an endpoint agents can use.

For web developers specifically, Safari joining Chrome in the agent-accessible browser club means true cross-engine autonomous testing is now possible: the same agent can verify a fix in Chromium and WebKit in a single session, without a human alt-tabbing between windows.

Current Limitations

Keep expectations calibrated — this is a preview:

  • Safari Technology Preview only. The MCP server is not in stable Safari yet, and Apple has not published a timeline for that.
  • macOS only. There is no way to point it at iOS Safari directly, though WebKit rendering on macOS catches most engine-specific issues.
  • No custom tools. The 16 tools are fixed; there is no extension mechanism today.

Conclusion

The Safari MCP server turns the most historically closed major browser into an agent-native debugging surface, with a setup that takes under two minutes. If you already run Claude Code or another MCP client, install Safari Technology Preview, flip two settings, run one command, and ask your agent to find bugs on your site in Safari.

For teams building for MENA markets — where iOS traffic share makes WebKit compatibility non-negotiable — this closes a real gap in autonomous testing workflows. And as the second first-party MCP server from Apple in a month, it is the strongest signal yet that the protocol has crossed from experiment to infrastructure.

The browser is now a tool your agent can hold. Use it.