I wonder if it supports Private Relay. Private Relay is great for getting around scraping blocks because they explicitly whitelist apple private Relay ips.
Building something similar for Chrome and Firefox browsers: https://github.com/DO-SAY-GO/WebCLI - a CLI not MCP. Tho am considering MCP for distribution, even tho agents love the CLI and the proof demos speak for themselves.
The reason I did not include Safari was there wasn't enough parity between its Safaridriver surface and what Bidi/CDP give now. Safari is doing Bidi tho, iirc. So ...soon perhaps. ;) ;p xx ;p
> There are many ways to build for the web, both with and without AI. If AI is a part of your workflow, we think this tool will help make it even more productive. And if it isn’t, that’s OK too.
Crazy thing to say in 2026 where if you write code and not delegate every bit to an agent you're considered a noob by some people.
MCP for browser automation is interesting because Safari's WebKit engine is the one most AI agents can't easily drive (Playwright and Puppeteer are Chromium-first). Having an MCP server for it could fill a real gap in cross-browser testing for agent workflows.
I am especially hopeful for this for my daily stuff, not just testing.
Meaning, having a hopefully seamless way to perform some automations in the browser on my behalf but since it’s the browser I’m logged in to, it just makes the handoff between myself and the agent feel more seamless.
And that’s because I’ve used safari as my main browser, not chrome, because it isn’t as much of a battery hog.
Federico Viticci went into a little more detail about what this means on MacStories, Mastodon, and the latest episode of the Connected podcast. It is also more approachable for laypeople.
Be sure to visit the links from the story, as well.
Have it write playwright code to debug. (for those who don’t know, Playwright is a system and API that lets you write code to drive a headless (invisible) browser - “click the button with this DOM id, scroll to here, choose this dropdown option, click Submit, etc.)
Once it tracks down the bugs - boom! You have an end to end test to add to your suite.
22 comments
[ 3.3 ms ] story [ 41.5 ms ] threadThe reason I did not include Safari was there wasn't enough parity between its Safaridriver surface and what Bidi/CDP give now. Safari is doing Bidi tho, iirc. So ...soon perhaps. ;) ;p xx ;p
https://github.com/ChromeDevTools/chrome-devtools-mcp
Before that I used Chrome web drivers but MCP is faster and more capable.
I also instruct LLMs to test my pages on Firefox using its official MCP to make sure they work in Firefox too:
https://github.com/mozilla/firefox-devtools-mcp
Now I will add Safari to the compatibility tests. cool
How do you test on Safari if you don’t have Apple devices?
How difficult can it be for Apple to make barebones virtual machines with just Safaris?
It works much faster for me than the MCP servers I tried.
Crazy thing to say in 2026 where if you write code and not delegate every bit to an agent you're considered a noob by some people.
Meaning, having a hopefully seamless way to perform some automations in the browser on my behalf but since it’s the browser I’m logged in to, it just makes the handoff between myself and the agent feel more seamless.
And that’s because I’ve used safari as my main browser, not chrome, because it isn’t as much of a battery hog.
Be sure to visit the links from the story, as well.
https://www.macstories.net/linked/safaris-new-mcp-server-is-...
https://mastodon.macstories.net/@viticci/116847167023618099
https://relay.fm/connected/610
Have it write playwright code to debug. (for those who don’t know, Playwright is a system and API that lets you write code to drive a headless (invisible) browser - “click the button with this DOM id, scroll to here, choose this dropdown option, click Submit, etc.)
Once it tracks down the bugs - boom! You have an end to end test to add to your suite.