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 (headers, auth, cookies...).
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 isolate 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
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.
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).
All this felt heavy to me. Full browser, debug protocol, DOM dump on every read. MCP vs CLI is the smaller question, what sits underneath matters more. So I built a small Rust binary that drives the system webview directly and returns state tokens and deltas instead of the DOM. Loading the HN front page costs the agent about 50 tokens. It speaks both MCP and CLI, pick whichever your agent prefers.
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
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.
> 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.
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.
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.
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 the physical touch experience that emulators cannot emulate. I don't resent these purchases, because I understand it's the reality of developing for a diverse open 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 instinctively 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.
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 have multiple Playwright webkits on both Windows and Linux. I have Epiphany on Linux (not 100% same webkit). I have subscriptions for testing on real hardware.
This is why it seems to me that Apple does not really care about web developers.
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.
### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# Changes to this file will not be preserved.
# This file will not be recreated if removed.
X-Repolib-Name: Microsoft Edge
Types: deb
URIs: https://packages.microsoft.com/repos/edge-stable
Suites: stable
Components: main
Architectures: amd64
Architectures: amd64
Signed-By: /usr/share/keyrings/microsoft-edge.gpg
First, the Microsoft browser these days is Edge, not IE. IE is dead.
Second, if you want, or wanted in the past, to test on Internet Explorer without a Windows computer, you could just virtualize Windows. Windows can be legally virtualized on any hardware and on any host operating system.
Starting from 2013, you didn’t even need to pay for a Windows license to do that:
Are seriously asking with a straight face? Just do what a generation of people have done with Windows and run an unlicensed version of macOS. There's a whole generation of people who can recite Windows product keys off by heart. (FCKGW, anyone?) Entire empires of indie web development will have been done on improperly licensed versions of Windows.
As for people working in a serious professional corporation that cannot condone casual piracy, buy a Mac mini and expense it, or get an account on MacStadium.
The owner of whirlpool.net.au commenting on my comment.
I am replying because of the huge respect I have for the work.
Yes, I am seriously asking with a straight face.
Yes, I know how to pirate. I’m from this planet. :-D
Pirating, and jumping through hoops to do things certain vendors didn’t want done, was fun while I was learning. And educational. Super educational, in many respects.
But it is not fun anymore for me. There are other things these days that can get me banging my head against walls, and they are, in total, more fun and more educational.
My point is only that testing on any non-free platform involves jumping through non-free or non-legal hoops. Testing on a variety of platforms/clients shouldn't be considered a chore. It's a necessary part of having a truly open, truly free web. Don't complain that you have to buy an Apple device. Say thank you. Seriously.
Diversity — not choice — is what keeps the web truly open and truly free. Enforced diversity sometimes sucks for the individual but necessary for the healt of the ecosystem. The "choice" of Chromium everywhere isn't a choice, it's forcing everyone into a monoculture. When everyone is expected to use one browser engine, the open web is dead.
Because it cannot run Chromium, Safari on iPhone is the last refuge of the truly open and truly free web. Steve Jobs might be known for many things, but I think he's under-appreciated as a two-time saviour of the web; first by destroying Adobe Flash[0], and second by ensuring that one web browser couldn't dominate on all platforms.
[0] To this day I am utterly stunned that anyone in a community like Hacker News would think it acceptable that a significant chunk of the web was under the thumb of a proprietary, closed source binary blob. The death of Flash was necessary, righteous, and overdue.
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.
https://developer.apple.com/icloud/prepare-your-network-for-... has a guide for web server operators, including a GeoIP CSV which could conceivably be used for whitelisting. More concerning is that they're plugging private access tokens there, which allows Apple to vouch that you're a human running their hardware.
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.
> 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.
That’s the point I think. Remember the controversy when Github Copilot came out? Not because where it got its data from, but because people didn’t feel like they wrote code anymore, they just tabbed the autocompleted snippets and was finished with a task in much shorter time.
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.
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.
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
Introducing a new Linux distribution which comes with the yiff sound server, the GIMP image editor, and provides for web browsing entirely using FuckUI.
Marketing iterations. Plus dang downweighted my posts after I got the biggest Show HN of last year, so I'm trying harder to get attn. HN maybe isn't the big launch - but it's kinda a legacy thing for me. Can't blame a guy for tryin
I have been using Chrome's official MCP devtools server since Nov 2025.
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
Is there a difference between using these and using the playwright mcp with Chrome/Firefox config?
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 (headers, auth, cookies...).
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 isolate bottlenecks and unnecessary repaints and reflows.
Network request access is really helpful!
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
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.
https://www.macstories.net/linked/safaris-new-mcp-server-is-...
https://mastodon.macstories.net/@viticci/116847167023618099
https://relay.fm/connected/610
I'd personally suggest Playwright-CLI: https://github.com/microsoft/playwright-cli
It works much faster for me than the MCP servers I tried.
Also, spel (https://github.com/Blockether/spel) for persistent browser sessions (through a daemon) and Chromium, Firefox, and WebKit engines.
playwright is AWESOME for e2e testing (works great with electron!).
although, i use the playwright mcp. :)
The CLI is, IME, faster and less buggy than the MCP.
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).
i will be digging into the CLI option, kudos.
All this felt heavy to me. Full browser, debug protocol, DOM dump on every read. MCP vs CLI is the smaller question, what sits underneath matters more. So I built a small Rust binary that drives the system webview directly and returns state tokens and deltas instead of the DOM. Loading the HN front page costs the agent about 50 tokens. It speaks both MCP and CLI, pick whichever your agent prefers.
https://github.com/frane/vibesurfer
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.
I'm working on Hyperia and it has full agentic control of a webpane (Electron based) for doing crazy things with it: https://github.com/deepbluedynamics/hyperia.
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.
> It also does not have access to your personal information in Safari (e.g. AutoFill or other browser activity).
I read this as meaning you won't be logged into the instance the agent interacts with
> it just makes the handoff between myself and the agent feel more seamless.
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.
[flagged]
There has been the (Apple provided) safaridriver for a couple of years. It speaks WebDriver W3C and can be used to interact with a Safari instance.
Why waste tokens letting your agent use an MCP?
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.
But does Apple really care about web developers?
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?
> 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.
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.
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.
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 the physical touch experience that emulators cannot emulate. I don't resent these purchases, because I understand it's the reality of developing for a diverse open 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 instinctively 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.
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…
quote: "GitHub-hosted runners are available with Ubuntu Linux, Windows, or macOS operating systems." source: https://docs.github.com/en/actions/concepts/runners/github-h...
> 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.
GitHub has been providing macOS runners for a while now.
Even in the Chrome hegemony you don't want to be missing Edge and many others, so you test chromium.
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.
I know of the solutions. I use a few of them.
I have multiple Playwright webkits on both Windows and Linux. I have Epiphany on Linux (not 100% same webkit). I have subscriptions for testing on real hardware.
This is why it seems to me that Apple does not really care about web developers.
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.
> But does Apple really care about web developers?
They just released this new tool, so yes.
Just like you would test IE on Linux or OS X.
I said IE, not Edge.
But why would you still test for IE in 2026?
Honest question. I’s < .5% market share and retired since 2023.
I think pjmlp is just being contrarian.
First, the Microsoft browser these days is Edge, not IE. IE is dead.
Second, if you want, or wanted in the past, to test on Internet Explorer without a Windows computer, you could just virtualize Windows. Windows can be legally virtualized on any hardware and on any host operating system.
Starting from 2013, you didn’t even need to pay for a Windows license to do that:
https://archive.org/details/modern.ie-vm
Nope, making a point.
You would still need a VM for that.
Just like you can get a macOS VM, plenty of ways to get them.
What plenty of ways?
How can I run a macOS virtual machine LEGALLY on my Linux or Windows machine?
Are seriously asking with a straight face? Just do what a generation of people have done with Windows and run an unlicensed version of macOS. There's a whole generation of people who can recite Windows product keys off by heart. (FCKGW, anyone?) Entire empires of indie web development will have been done on improperly licensed versions of Windows.
As for people working in a serious professional corporation that cannot condone casual piracy, buy a Mac mini and expense it, or get an account on MacStadium.
F*** me!
The owner of whirlpool.net.au commenting on my comment.
I am replying because of the huge respect I have for the work.
Yes, I am seriously asking with a straight face.
Yes, I know how to pirate. I’m from this planet. :-D
Pirating, and jumping through hoops to do things certain vendors didn’t want done, was fun while I was learning. And educational. Super educational, in many respects.
But it is not fun anymore for me. There are other things these days that can get me banging my head against walls, and they are, in total, more fun and more educational.
Hi. :-D
My point is only that testing on any non-free platform involves jumping through non-free or non-legal hoops. Testing on a variety of platforms/clients shouldn't be considered a chore. It's a necessary part of having a truly open, truly free web. Don't complain that you have to buy an Apple device. Say thank you. Seriously.
Diversity — not choice — is what keeps the web truly open and truly free. Enforced diversity sometimes sucks for the individual but necessary for the healt of the ecosystem. The "choice" of Chromium everywhere isn't a choice, it's forcing everyone into a monoculture. When everyone is expected to use one browser engine, the open web is dead.
Because it cannot run Chromium, Safari on iPhone is the last refuge of the truly open and truly free web. Steve Jobs might be known for many things, but I think he's under-appreciated as a two-time saviour of the web; first by destroying Adobe Flash[0], and second by ensuring that one web browser couldn't dominate on all platforms.
[0] To this day I am utterly stunned that anyone in a community like Hacker News would think it acceptable that a significant chunk of the web was under the thumb of a proprietary, closed source binary blob. The death of Flash was necessary, righteous, and overdue.
There are the illegal ones, and the legal ones on cloud providers.
Making a point that Microsoft just like Apple, didn't necessarily made it easier.
Naturally Chrome forks work everywhere, given that so many devs have sponsored Google's takeover the Web.
Microsoft actually offered free VMs with different OS and IE versions to make testing easier.
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.
Which sites explicitly whitelist Private Relay IPs?
https://developer.apple.com/icloud/prepare-your-network-for-... has a guide for web server operators, including a GeoIP CSV which could conceivably be used for whitelisting. More concerning is that they're plugging private access tokens there, which allows Apple to vouch that you're a human running their hardware.
I've been telling agents to run Chrome and talk to it directly via the CDP recently and finding that to work very well.
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.
Indeed. This works much better and faster than the mcp route.
> 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.
When have people using AI to develop ever had to hide in any closet? It's the most public "new hotness" ever.
That’s the point I think. Remember the controversy when Github Copilot came out? Not because where it got its data from, but because people didn’t feel like they wrote code anymore, they just tabbed the autocompleted snippets and was finished with a task in much shorter time.
It wasn't nearly as good 2 years ago.
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.
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.
Does the websites get some flag or clue that this is an AI bot interacting?
How are the MCP servers compared to Playwright?
PLayWright is not built into browsers...?
What is the difference in functionality?
With PlayWright you find bugs and with MCP you remove them.
Does this support mobile simulator safari too
so it's a crossover of dev tools and LLM? sounds sane enough i'd say
should say "see how my website performs on safari"
[flagged]
[dead]
[flagged]
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
Not sure you want to hear this but there is 0% chance I will ever bring up a product with a vulgar name at work.
Introducing a new Linux distribution which comes with the yiff sound server, the GIMP image editor, and provides for web browsing entirely using FuckUI.
Hahahaha lol. That’s a good point.
I understand that. Hence the name ‘correction’
Not really sure why your project needs to be so… edgy?
Marketing iterations. Plus dang downweighted my posts after I got the biggest Show HN of last year, so I'm trying harder to get attn. HN maybe isn't the big launch - but it's kinda a legacy thing for me. Can't blame a guy for tryin
The actual site is: https://duetbrowser.com/