I wonder if it supports Private Relay. Private Relay is great for getting around scraping blocks because they explicitly whitelist apple private Relay ips.
Should do. Private relay really would be a sweet alternative to residential scraping proxies, but I’d expect sites to put in additionally checks and captchas before too long.
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
I can speak for Chrome's MCP which I have more experience.
devtools MCP will have access to more deep level fetures such as performance profiling, lighthouse and network requests in details.
For example, I had success using chrome devtools mcp to debug frontend performance issues. The LLM captured and analyzed some nice traces and was able to spot bottlenecks and unnecessary repaints and reflows.
When having access to both backend and frontend, and then seeing what actual code is requesting and returning can really help with hunting bugs or doing basic QA.
I used the chrome MCP to profile a slow react page at my company, set a /goal and had it iterate until it achieved under 100ms responsiveness to actions.
Claude was able to identify the slowness and use various react tricks to fix the specific issues, all without my input.
I don’t think the playwright MCP can do this, unless I’m mistaken
Sometimes I find myself wanting the other way round, instead of letting LLM tell browser what to do, I want what I did manually in the browser be visible to LLM. I made a MCP to cover that use case
No way, is Orion Browser available on other platforms as well now? Does it mean I can finally do tests for Safari (webkit) without owning an Apple product or paying for a vm? Incredible.
> How do you test on Safari if you don’t have Apple devices?
How do you test a Playstation game without a Playstation (dev kit)? How do you test some hardware firmware without having the hardware? How can you run a program without the hardware required to run the program, if no emulator/simulator is available?
I'm almost lost at words how these are questions, unless they're theoretical and some diatribe comes afterwards that has the actual point trying to be made, but it never came.
Yes, some things run only on specific hardware and without virtualization/emulation, you're not supposed to test those things outside of the hardware. Been a thing for decades, probably since the beginning of computing.
> How difficult can it be for Apple to make barebones virtual machines with just Safaris?
Almost nothing Apple does is seemingly decided by how difficult it is, for better or worse, but are strategic decisions. If you haven't caught up with that they're building a walled garden for themselves, I'm not sure what could convince that they are. I think this is extremely clear for most people. If you don't like it, don't play there, like the rest of us.
A lot of folks want to run tests off a GitHub action I.e. on a server somewhere.
Ideally you want your test stack to fit in a docker image. So this does suck for developers in the respect and you could imagine apple releasing a special docker image that just ran safari if they wanted to really make it easy to develop for thier platform.
However, I imagine someone will fill a server rack with cheap old macs and offer and safari mcp as a service…
> A lot of folks want to run tests off a GitHub action I.e. on a server somewhere.
Understandable, but also if you're dealing with these sort of projects, you kind of have to setup that sort of automation yourself in an office/someone's house, unless you find some provider that already hosts that sort of thing, like the various Apple/vendor-specific services for that.
It's also not a very new thing really, MacStadium for example been around since like 2010 sometime.
I don't think it's fair to compare development for web, which is supposed to be an open standard, with developing for a proprietary piece of hardware like the Playstation.
If you want to develop a game for the Switch and ignore the Playstation entirely, you can, and then you don't need a Playstation (dev kit).
When you're developing for the web, you're ideally making something that runs regardless of the user's browser. When you start getting bug reports in from Safari users, how else are you supposed to fix them? Cheapest option is detect if they're a Safari user and tell them to use another browser, but that's not really ideal for anyone except Google.
Having access to a representative spread of devices is the reality of web development. As a web developer that doesn't own any Android devices, I was "forced" to buy a couple of Android devices so that I could squash bugs (some of which couldn't be replicated in emulators) and to refine aspects of touch UX for Android users. I don't resent these purchases, because I understand it's the reality of a diverse web.
And yet, oh how often I hear developers resent having to buy an Apple device. Every time, I look at my little stack of Android devices and impulsively roll my eyes.
> Cheapest option is detect if they're a Safari user and tell them to use another browser
I suppose the cheapest option for me was to detect if they're an Android user and tell them to use another device. It sounds silly to say it — it is silly to say it — but that's exactly the same logic.
If you're developing for the web and you're not testing you're site on real hardware, including a handful of iPhones and a handful of Android devices, your not actually testing your software.
You can't just check Chrome and assume everything else will exhibit the same behaviors. Standards exists, but so do bugs.
the CLI is also Microsoft's preferred way to use it with agents:
> playwright-cli is best for coding agents (Claude Code, GitHub Copilot, etc.) that favor token-efficient, skill-based workflows. CLI commands avoid loading large tool schemas and verbose accessibility trees into the model context.
they do still recommend the MCP for long-running autonomous workflows (e.g. a UAT agent).
> 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.
The opposite was considered two years ago a crazy thing to say. I'm glad this changed and people using ai don't have to hide in the closet anymore for doing so.
Which part makes it crazy? The fact that they felt the need to add this disclaimer to try to assuage the fanatical anti-AI contingent?
Like this is specifically a tool for AI-augmented development, and they had to add this "but also, thoughts and prayers for you non-AI people" is incredibly weird, but not in the way you seem to think it is.
I want to love Safari but it just sucks! The new IE.
Until it can run 3D, video, and other media well and as long as it has special styles for CSS that no other browser does it will always be annoying to developers.
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'll have to try that. how does it compare to using playwright? it seems like one advantage of playwright is being able to use it with multiple browsers, at least as far as web development goes. if these browser-specific tools end up being faster or more token efficient then it's probably the better pick for task automation and claws
Yeah, the big advantage of playwright is that it's cross-browser. It's still my go-to tool for automated testing - I use the CDP trick for one-off automation tasks.
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.
Uses an agent container orchestrator as well, which has MCP tools to expose ports in the container (and thus can display the work in the webpane): https://github.com/DeepBlueDynamics/nemesis8
Federico Viticci went into a little more detail about what this means on MacStories 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.
65 comments
[ 2.8 ms ] story [ 67.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
devtools MCP will have access to more deep level fetures such as performance profiling, lighthouse and network requests in details.
For example, I had success using chrome devtools mcp to debug frontend performance issues. The LLM captured and analyzed some nice traces and was able to spot bottlenecks and unnecessary repaints and reflows.
When having access to both backend and frontend, and then seeing what actual code is requesting and returning can really help with hunting bugs or doing basic QA.
Claude was able to identify the slowness and use various react tricks to fix the specific issues, all without my input.
I don’t think the playwright MCP can do this, unless I’m mistaken
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?
Similarly, while not perfect you can test WebKit, and if you like, on Linux or Windows, for example:
https://orionbrowser.com/platforms/linux
Apple wouldn't be in the business of VMs with Safari, but if you're looking for MacOS VMs, turn to a CSP: https://aws.amazon.com/ec2/instance-types/mac/
Many have software testing orchestration pre-wired.
How do you test a Playstation game without a Playstation (dev kit)? How do you test some hardware firmware without having the hardware? How can you run a program without the hardware required to run the program, if no emulator/simulator is available?
I'm almost lost at words how these are questions, unless they're theoretical and some diatribe comes afterwards that has the actual point trying to be made, but it never came.
Yes, some things run only on specific hardware and without virtualization/emulation, you're not supposed to test those things outside of the hardware. Been a thing for decades, probably since the beginning of computing.
> How difficult can it be for Apple to make barebones virtual machines with just Safaris?
Almost nothing Apple does is seemingly decided by how difficult it is, for better or worse, but are strategic decisions. If you haven't caught up with that they're building a walled garden for themselves, I'm not sure what could convince that they are. I think this is extremely clear for most people. If you don't like it, don't play there, like the rest of us.
However, I imagine someone will fill a server rack with cheap old macs and offer and safari mcp as a service…
Understandable, but also if you're dealing with these sort of projects, you kind of have to setup that sort of automation yourself in an office/someone's house, unless you find some provider that already hosts that sort of thing, like the various Apple/vendor-specific services for that.
It's also not a very new thing really, MacStadium for example been around since like 2010 sometime.
If you want to develop a game for the Switch and ignore the Playstation entirely, you can, and then you don't need a Playstation (dev kit).
When you're developing for the web, you're ideally making something that runs regardless of the user's browser. When you start getting bug reports in from Safari users, how else are you supposed to fix them? Cheapest option is detect if they're a Safari user and tell them to use another browser, but that's not really ideal for anyone except Google.
And yet, oh how often I hear developers resent having to buy an Apple device. Every time, I look at my little stack of Android devices and impulsively roll my eyes.
> Cheapest option is detect if they're a Safari user and tell them to use another browser
I suppose the cheapest option for me was to detect if they're an Android user and tell them to use another device. It sounds silly to say it — it is silly to say it — but that's exactly the same logic.
You can't just check Chrome and assume everything else will exhibit the same behaviors. Standards exists, but so do bugs.
Safari is the new IE.
App Store isn’t dev friendly either - make you jump thru hoops, payouts like a month or two later. Awful dev experience compared to anything else.
They just released this new tool, so yes.
It works much faster for me than the MCP servers I tried.
> playwright-cli is best for coding agents (Claude Code, GitHub Copilot, etc.) that favor token-efficient, skill-based workflows. CLI commands avoid loading large tool schemas and verbose accessibility trees into the model context.
they do still recommend the MCP for long-running autonomous workflows (e.g. a UAT agent).
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.
Like this is specifically a tool for AI-augmented development, and they had to add this "but also, thoughts and prayers for you non-AI people" is incredibly weird, but not in the way you seem to think it is.
Until it can run 3D, video, and other media well and as long as it has special styles for CSS that no other browser does it will always be annoying to developers.
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.
Uses an agent container orchestrator as well, which has MCP tools to expose ports in the container (and thus can display the work in the webpane): https://github.com/DeepBlueDynamics/nemesis8
I'll add the Safari MCP wiring to n8 today...
New releases landing tonight with more features.
I read this as meaning you won't be logged into the instance the agent interacts with
This terrifies me because there's no way for the services on the other side of the browser to know who is doing what.
How do you constrain the agent?
How do you keep track of what you have done vs the agent?
What am I missing? Am I just behind the times?
Edit, added reference to what terrifies me.
Be sure to visit the links from the story, as well.
https://www.macstories.net/linked/safaris-new-mcp-server-is-...
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.