navette — the browser for agents MCP server

navette — v1.9.0

The browser for agents. One tiny Rust binary driving the WebView your OS already ships — no Chromium, no download, no RAM bonfire.

Navette is French for shuttle — the small vessel that carries your agent from page to page. Always fueled (the engine ships with your OS), light enough to ignore, and it skips the human web's garbage so your agent doesn't have to.

Single Rust binary, three modes:

$ ls -lh target/release/navette
-rwxr-xr-x  1 user  staff   725K  navette

725 KB installed on macOS (release binaries track it; the OS-keychain store for logged-in states costs ~100 KB). Windows-x64 / linux-x64 ride the wry backends. Playwright ships 218 MB. Lightpanda ships 96 MB (and cannot screenshot). Measured claims, reproducible with one command (BENCHMARKS.md):

• Faster than Playwright + Chromium on every metric we measured — install, cold start, navigate→read (8 ms), act (1 ms), peak RAM, 100-page crawl (0.9–2.8 s, parity with Lightpanda within variance and ~2–3x faster than Playwright), real-web success rate (95–100% vs 85%).
• Crawls at Lightpanda's speed while rendering (parity within variance through the zero-bias raw-CDP probe, where Lightpanda is the fastest page-reader at 3.3–3.4 ms — it parses a partial DOM and cannot render — and navette is the fastest full-rendering reader: 17.9–19.4 ms vs Chromium's 28–34 ms through the identical client).
• The two rows Lightpanda wins — fresh-process boot and peak RAM — are the price of rendering. If your agent only reads static pages, use fetch + readability; if it needs JS, sessions, actions and vision, that price is the product.

FAQ

Why not Apple's Safari MCP server (2026)? Same thesis, different scope: navette is agent-first (8 primitives, ghost windows, resident daemon), open source, and cross-platform by design (WebView2 on Windows is Chromium — preinstalled). Apple's is macOS-and-Safari-shaped.

Why not just fetch + readability? For static pages, do that — it beats everyone. navette exists for what fetch can't do: JS-built pages, logins, sessions, forms, screenshots, acting like a human.

Why not an ML extraction model? Two trades, not a ranking — pulpie-mcp lives on the ML side of this lane. Trained extraction models survive hostile HTML — agency templates, mangled CMS output — where a DOM walk picks the wrong node, at roughly ~600 ms of compute per page. navette's native DOM walk costs ~10 ms per page and wins wherever the markup is sane, which is most documentation, news and dev-tool pages — most of what agents actually read. The layers compose: when one target's markup is hostile enough that native extraction picks garbage, hand that page's raw HTML to an ML pass.

Is navette a crawler? No — deliberately. navette does navigate/read/screenshot/act on a URL you hand it; robots → sitemap → link discovery is a layer above, not a core primitive. Point a crawler at navette when its targets need a real engine.

Screenshot fidelity? Capture is native per engine (v1.3+) — what the compositor drew, not a re-render — and viewport-sized; set the viewport before navigating for repeatable captures. Full-page capture is not implemented yet; tracked honestly rather than approximated.

Shortened. The full README is on GitHub.