# A rival to my open-source tool shipped. I read all of it — then ported its 4 best ideas the same afternoon. > Source: > Published: 2026-06-18 16:40:24+00:00 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](https://github.com/achiya-automation/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 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](https://github.com/achiya-automation/safari-mcp)), 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](https://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?