Author here. Some context that didn't fit in the title.
I built safari-mcp a few weeks ago — a macOS-native Safari automation MCP server (no Chrome, no headless, keeps Safari logins). 84 tools via the Model Context Protocol, used directly by Claude Code, Cursor, Cline, etc.
When I saw HKUDS/CLI-Anything (29k stars, auto-wraps open-source software as agent-native CLIs), I wondered if wrapping safari-mcp as a CLI was actually a good idea — so I benchmarked it before shipping.
The numbers, measured live against real Safari:
Per-call latency (10x list_tabs, warm cache):
MCP (persistent stdio session): 119ms median
CLI (subprocess per call): 3,023ms median
MCP is 25.3x faster.
5-op reactive workflow:
MCP: 2.7s
CLI sequential: 15.3s
CLI shell pipeline: 15.2s
MCP 5.6x faster (pipelining does NOT amortize npx spawn).
Token overhead per API call (real tools.json, cl100k_base tokenizer):
MCP (84 tool definitions): 7,986 tokens
CLI (just `bash` tool def): 95 tokens
CLI 84x fewer per-call tokens.
Accuracy: byte-identical output (both paths hit the same safari-mcp).
So for Claude Code / Cursor / Cline users, MCP is the right answer — 25x lower latency per call. I say this up front in the harness's README and SKILL.md.
The CLI exists for a different audience:
- Agents that don't speak MCP (Codex CLI, GitHub Copilot CLI, older frameworks, bash scripts)
- CI / cron — subprocess-friendly, jq-pipeable JSON output
- Long Opus sessions where tool-def tokens dominate cost. At $15/MTok input, sending 7,986 tokens of tool definitions on every API call adds up. 100-turn session: ~$12 in tool-def overhead for MCP vs ~$0.22 for CLI. Prompt caching narrows the gap to ~10x but it's still real money at scale.
The harness is schema-driven: an offline parser reads safari-mcp's Zod definitions, emits a JSON bundle, and at import time safari_cli.py generates 84 Click commands from it — zero manual mapping, parity tests pin the result. The parser went through 5 review rounds before I caught everything, including a sneaky nested-schema bug where .describe() was picked from the inner field instead of the outer.
Happy to answer questions about the architecture, the benchmark methodology, or why it took 5 review rounds to find all the bugs.
Interesting approach building a dedicated browser for AI agents. The browser-as-infrastructure angle makes sense — most MCP browser servers just wrap Chrome with CDP, which adds significant overhead.
One thing I've been thinking about is whether we even need a separate browser process. On macOS, Safari's AppleScript bridge lets you run JS in any tab without launching anything new. Your existing browser with all its sessions is already there.
The trade-off is obvious though: a purpose-built browser like Vessel can add agent-specific features (structured DOM output, action recording) that you'd never get from a general-purpose browser's scripting API.
How are you handling authenticated sessions? That's been the biggest pain point I've seen with headless/separate browser approaches — users have to re-login or copy cookies.
I built safari-mcp a few weeks ago — a macOS-native Safari automation MCP server (no Chrome, no headless, keeps Safari logins). 84 tools via the Model Context Protocol, used directly by Claude Code, Cursor, Cline, etc.
When I saw HKUDS/CLI-Anything (29k stars, auto-wraps open-source software as agent-native CLIs), I wondered if wrapping safari-mcp as a CLI was actually a good idea — so I benchmarked it before shipping.
The numbers, measured live against real Safari:
So for Claude Code / Cursor / Cline users, MCP is the right answer — 25x lower latency per call. I say this up front in the harness's README and SKILL.md.
The CLI exists for a different audience:
- Agents that don't speak MCP (Codex CLI, GitHub Copilot CLI, older frameworks, bash scripts) - CI / cron — subprocess-friendly, jq-pipeable JSON output - Long Opus sessions where tool-def tokens dominate cost. At $15/MTok input, sending 7,986 tokens of tool definitions on every API call adds up. 100-turn session: ~$12 in tool-def overhead for MCP vs ~$0.22 for CLI. Prompt caching narrows the gap to ~10x but it's still real money at scale.
The harness is schema-driven: an offline parser reads safari-mcp's Zod definitions, emits a JSON bundle, and at import time safari_cli.py generates 84 Click commands from it — zero manual mapping, parity tests pin the result. The parser went through 5 review rounds before I caught everything, including a sneaky nested-schema bug where .describe() was picked from the inner field instead of the outer.
Happy to answer questions about the architecture, the benchmark methodology, or why it took 5 review rounds to find all the bugs.
Full writeup with methodology and the bug post-mortems: https://dev.to/achiya-automation/mcp-vs-cli-for-browser-auto...
safari-mcp repo: https://github.com/achiya-automation/safari-mcp