Kitewright

Browser automation for AI agents as a single small binary. An MCP server (Streamable HTTP + stdio) that gives LLM clients navigate / screenshot / extract — without carrying the Node.js + Playwright stack.

Install in one line:

claude mcp add kitewright -- npx -y @kitewright/mcp

Why — measured, not claimed

Head-to-head vs @playwright/mcp 0.0.78, same machine, same Chromium headless-shell build, same page (full methodology):

The browser itself (Chromium) costs the same in any language — warm latency is a tie because both speak CDP to the same browser. The wins are everything around it: startup, distribution, idle footprint, and lifecycle management. The honest gap: playwright-mcp ships ~25 tools today, we ship 21 — closing that is the roadmap.

Reliability — actionability auto-waiting

click / type / fill_form / select_option / hover don't fire blindly. Before acting, the engine polls (100 ms, up to a 5 s per-op budget) until the target element is present, visible (not display:none / visibility:hidden / zero-size), enabled (no disabled / aria-disabled), not covered by another element at its click point, and geometrically stable across two consecutive frames. A settled element passes on the first poll, so this is invisible when things are fine — but when an action can't happen, you get a cause-specific error (not found / not visible / disabled / covered / unstable) instead of a silent misclick or a generic timeout. Transient CDP errors are retried twice. Pass timeout_ms on any interaction tool to override the 5 s per-op budget (e.g. a short timeout to fail fast when you expect an element to already be there).

Performance

External-site latency is network-bound — DNS + TLS + TTFB (~400–600 ms) is a floor no tool beats, and Kitewright does not claim to. What it does attack is every controllable cost around the network:

• Prewarm + warm-context pool. The moment an MCP session initializes, the server launches the browser and fills a small pool of pre-created blank browser contexts (MCP_CONTEXT_POOL, default 2) in the background. A new session is then handed a ready context+page, so its first navigate pays zero browser-launch and zero context-creation cost. Measured localhost first-navigate: ~31 ms prewarmed vs ~709 ms cold (Apple Silicon; details). The pool drains with the browser on idle-reap and refills lazily on next demand, so idle footprint stays at the ~8 MB baseline.
• Lite mode. browser_navigate {lite:true} (and the default for extract / extract_markdown) blocks images/media/fonts + ad/analytics hosts before the load — 30–70 % faster DOM-ready on heavy pages by skipping the bulk of the bytes. Screenshots/PDF never block resources.
• Shared disk cache + connection pre-warm. A stable --disk-cache-dir (KITE_CACHE_DIR) lets repeat asset fetches hit cache across runs; KITE_PREWARM_URL establishes DNS+TLS to a known origin during prewarm.

The honest framing: the wins are browser launch, page weight, session start, and connection setup — not the network round-trip to a remote origin.

Architecture

crates/
├── engine/    kitewright-engine — CDP core (chromiumoxide): lazy launch, idle reaper,
│              per-session browser c

... [View full README on GitHub](https://github.com/kitewright/kitewright#readme)