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.
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
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
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.
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.
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.
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.
They just released this new tool, so yes.
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.
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.
The actual site is: https://duetbrowser.com/
although, i use the playwright mcp. :)
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.
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.
However, I imagine someone will fill a server rack with cheap old macs and offer and safari mcp as a service…
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
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.
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.
You can't just check Chrome and assume everything else will exhibit the same behaviors. Standards exists, but so do bugs.
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.
### 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
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.
Honest question. I’s < .5% market share and retired since 2023.
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:
Naturally Chrome forks work everywhere, given that so many devs have sponsored Google's takeover the Web.
You would still need a VM for that.
Just like you can get a macOS VM, plenty of ways to get them.
How can I run a macOS virtual machine LEGALLY on my Linux or Windows machine?
In Safari Technology Preview 247, we’re introducing the Safari MCP server — a Model Context Protocol server for web developers that makes your web development and debugging workflow faster and more powerful. We know agents are increasingly integral to the coding process and the Safari MCP server gives your agent the ability to know how your code actually renders in the browser by connecting it to a Safari browser window.
Any MCP-compatible client can connect to the Safari MCP server. By connecting your agent to a Safari browser window, your agent can emulate what your users experience, giving it the information it needs to debug more autonomously, like access to the DOM, network requests, screenshots, and console output.
It speeds up your debugging process and lets you stay in the comfort of your terminal, which means fewer rounds of hopping windows and typing prompts to debug your code.
If you build for the web, then you know about the debugging dance. It usually goes something like this:
You see something wrong with your site in the browser. You open the console to hunt it down. You click into the styles tab. You see what’s broken. You go back to your code to fix it. Or maybe you take a screenshot, detail the problem to your agent, and let it do the fixing for you. Hopefully it gets it right, the bug is fixed, and you can move on.
But when it isn’t fixed, you go through the workflow again — Browser. Prompt. Agent.
And again and again, until you finally squash the bug.
Regardless of the browser or tools you use, the debugging workflow is a lot of clicks, tools, and window hopping to make a single fix, but it doesn’t have to be that way. If you’re already using agents in your development workflow, the Safari MCP server makes your debugging faster and more efficient.
The Safari MCP server enables your agent to do more debugging and troubleshooting on its own. Here are just a few examples of what it can help with:
Web development in Safari. The next time you develop in Safari, you’ll benefit from an upgraded workflow. Your agent already helps you with your code, now it can do even more by checking out how your code actually renders in Safari.
Improve compatibility with Safari. Testing in just one browser means missing potential bugs in another, giving those users a subpar experience. With the Safari MCP server, your agent can open your site in Safari, inspect computed styles, check layout, and compare it against what you expect without switching windows.
Analyze performance. See what parts of your site are slowing things down. The Safari MCP server lets your agent evaluate JavaScript on the page to surface performance metrics, like navigation timing and resource load times, so it can pinpoint what’s slowing your site down and work on the right fix.
Check for accessibility. The Safari MCP server lets your agent check for common accessibility issues like missing labels, improper ARIA attributes, and poor contrast, so you can catch problems that impact your users.
Verify any user state. Know that the page is working and looking as it should. Your agent can check the state of the form, query an element using a selector, confirm specific interactions, show different states of a checkout flow, and more. Spend less time on these manual checks and empower the agent to do it for you.
These are just a few of the use cases. However you decide to implement it, the Safari MCP server helps your agent do more for you and reduce all the back and forth that web development often requires. An easier workflow means more bugs squashed, happier users, and a better product.
Here are the available tools and what they do:
| Tool | Description |
|---|---|
| browser_console_messages | Return buffered console logs for the current or specified tab |
| browser_dialogs | List and respond to browser dialogs (accept, dismiss, or input text for JS prompts) |
| close_tab | Close a browser tab by its handle |
| create_tab | Create a new browser tab, optionally loading a URL |
| evaluate_javascript | Execute JavaScript code within the page and return the result |
| get_network_request | Get full detail for a single recorded network request (headers, body, timing) |
| get_page_content | Extract text content of a page in various formats (markdown, HTML, JSON, etc.) |
| list_network_requests | List network request summaries (URL, method, status, timing) for the current tab |
| list_tabs | List all open browser tabs with their handles and URLs |
| navigate_to_url | Navigate to a URL and return the loaded page’s content |
| page_info | Get info about the current page: URL, title, and loading state |
| page_interactions | Perform DOM interactions in sequence: click, type, scroll, hover, keyPress, etc. |
| screenshot | Capture a screenshot of the current page as a PNG |
| set_emulated_media | Emulate a CSS media type (e.g. “print”) for responsive-design testing |
| set_viewport_size | Set the browser viewport size in CSS pixels |
| switch_tab | Switch to a different browser tab by its handle |
| wait_for_navigation | Wait for the current page to finish loading; returns final URL and title |
With the Safari MCP server, you no longer have to write the perfect prompt, carefully describing to your agent what you’re experiencing in the browser. You can give your agent the ability to find out for itself.
First you’ll need to install Safari Technology Preview. Once installed, make sure you enable Safari Settings > Advanced > Show features for web developers. Then go to Safari Settings > Developer > Enable remote automation and external agents.
If you’re using Claude, you can use the following command in your terminal:
claude mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp
If you’re using Codex, you can use the following command in your terminal:
codex mcp add safari-mcp-stp -- "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver" --mcp
For other agents, you can put the following in your mcp.json or config.json :
"safari-mcp-stp": {
"command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver",
"args": ["--mcp"]
}
Note that while the above code names the server safari-mcp-stp, you can name it whatever you like, even just safari. Once you have the Safari MCP server installed, try one of the following prompts:
Find bugs on my site in Safari
How accessible is my site in Safari?
See how my website performs in Safari
While each agent works a little differently, it shouldn’t need to be told to use the Safari MCP server explicitly — it’ll figure it out on its own. Simple prompts like the ones above are enough to kickstart the MCP.
Here’s how a conversation with an agent using the Safari MCP server might go:
You: Got a bug report — something’s broken in Safari on the flight page. Can you figure out what’s going on?
Agent: Sure, let me take a look.
Agent: I found two distinct bugs on the flight page in Safari. Want me to fix them both?
You: Yes. Anything else here that might be causing problems for Safari users?
Agent: Yes, two more things worth flagging. The results reveal animation is silently broken and the API server startup log is wrong. Should I tackle both as well?
All you need is an initial request to get started, and with the help of the Safari MCP server, your agent can take it from there.
The Safari MCP server runs entirely on your local machine and makes no network calls of its own. It also does not have access to your personal information in Safari (e.g. AutoFill or other browser activity). When it captures page content, screenshots, or console logs, that data goes directly to the agent you’re running — not to Apple. What happens to that data from there depends on the agent and model you’re using. As with any agent you give access to your browser, only use ones you trust.
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.
By creating this resource, we hope to make it easier than ever to test and debug in Safari by helping your agent understand how things look and work in the browser.
If you end up giving it a try or if this is your first time using an MCP server, let us know what you think.
Find us online: Saron Yitbarek on BlueSky, Jen Simmons on Bluesky / Mastodon, and Jon Davis on Bluesky / Mastodon. If you run into any issues, file a WebKit bug report. Filing issues really does make a difference.
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.