A new MCP server showed up in the official Model Context Protocol registry last week, three slots above mine: ** safari-devtools-mcp**. Same platform (macOS), same browser (Safari), same audience (AI coding agents). My first reaction was the honest one — a small jolt of
I maintain Safari MCP — a browser-automation server that drives your real, logged-in Safari through AppleScript and a native extension. No Chromium, no headless, no second browser melting your fan. So a competitor called "Safari DevTools MCP" is squarely in my lane.
Here's what I found, what I deliberately didn't copy, and the four tools I shipped into my own server before dinner.
The very first line of its package.json
told me most of the story:
"dependencies": {
"selenium-webdriver": "...",
"@modelcontextprotocol/sdk": "...",
"zod": "..."
}
It drives Safari through ** safaridriver** — Apple's official WebDriver. That's a legitimate, well-supported choice. But it's the exact choice my project exists to avoid. A WebDriver session launches a
Safari MCP does the opposite: it talks to the Safari you already have open, with all your auth intact, and never steals your foreground.
So I wasn't going to rip out my engine. Architecture is a position, not a feature. Copying it would erase the entire reason my tool exists.
But tools are a different question.
I dumped both tool lists and diff'd them. ~44 of its 48 tools mapped cleanly onto something I already had — click
, fill
, screenshot
, get_cookies
, network capture, the usual surface area.
Then there was a cluster of four that I had nothing equivalent to:
inspect_viewport_meta
get_safe_area_insets
check_ios_web_app_readiness
check_webkit_compatibility
This is a genuinely smart niche: iOS-Safari web-dev validation. The stuff every mobile web developer fights with — the notch, the viewport meta tag, "why won't my PWA add to the home screen," and Safari's long tail of CSS quirks. My server could automate Safari all day but couldn't answer any of those questions.
And here's the part that made it a no-brainer: all four are pure JavaScript inspection. No WebDriver capability, no protocol magic — just document.querySelector
, getComputedStyle
, and CSS.supports()
run inside the page. Which means they port directly onto my AppleScript do JavaScript
engine. The competitor's architecture wasn't portable. Its best ideas were.
Most "is this CSS supported in Safari?" tools work off a static database (think caniuse). They go stale, and they can't see your actual Safari version.
check_webkit_compatibility
does something better. It walks every stylesheet on the page, pulls each property: value
pair via the structured CSSOM (no regex — so custom properties don't create false positives), and then asks the live browser the only question that matters:
CSS.supports(property, value) // tested in THIS Safari, right now
If it fails unprefixed, it retries with -webkit-
. If that works, it tells you to add the prefix. If neither works, it's genuinely unsupported here. Then it layers on a tiny hand-curated list of behavioral quirks CSS.supports()
can't catch — like the classic:
position: sticky
silently fails inside anoverflow: hidden
/auto
ancestor. Useoverflow: clip
instead.
I reimplemented it as a synchronous IIFE returning JSON (my engine can't await
inside do JavaScript
— a [object Promise]
lesson I've written about before), wired it into a safari_webkit_compat
tool, and tested it against a live page with a deliberately sticky header:
{ "totalProperties": 6, "ok": false,
"quirks": ["position:sticky silently fails inside an overflow:hidden/auto ancestor…"] }
Caught it. The other three — safari_inspect_viewport
, safari_safe_area_insets
, safari_check_pwa
— went in the same way, each verified against a controlled DOM in real Safari before I trusted it.
I ported four ideas. I rewrote every line to fit my engine and my conventions, credited the inspiration, and skipped the parts that conflicted with what my project is. That feels like the honest version of "competition makes everything better" — not a press-release platitude, but a real afternoon of reading someone else's careful work and being better for it.
A rival didn't make my tool worse. It handed me a roadmap for a category — iOS web-dev validation — I hadn't even thought to cover.
If you're building on macOS and want an agent that drives your actual Safari (logged in, no headless), it's one line: npx safari-mcp
. The four new validators shipped in v2.14.0 (out now). More at achiya-automation.com.
Question for the room: when a competitor ships, do you read their code? I used to skip it out of some weird pride. I don't anymore. Where do you land — study it closely, or deliberately look away to protect your own taste?