A rival to my open-source tool shipped. I read all of it — then ported its 4 best ideas the same afternoon.

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 oh no. My second reaction was more useful: I cloned it and read the entire thing.

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 architectural fork in the road

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 clean, isolated automation instance of Safari: no cookies, no logins, no sessions, a "Safari is controlled by automation" banner across the top. It's the headless-browser problem wearing a Safari costume.

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.

Diffing 48 tools against my 91

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.

The one I like most: compatibility checking with zero false positives

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 an overflow: hidden/auto ancestor. Use overflow: 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.

What I took, and what competition is actually for

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?