Kitewright logo

Kitewright

by kitewright

Lightweight browser automation for AI agents: navigate, screenshot, extract, PDF. One small binary.

Install Kitewright

Pick your client, then add it in one click or paste the config.

STDIONode.js
~/Library/Application Support/Claude/claude_desktop_config.json
claude_desktop_config.json
{
  "mcpServers": {
    "mcp-303": {
      "command": "npx",
      "args": [
        "-y",
        "@kitewright/mcp"
      ]
    }
  }
}

Settings → Developer → Edit Config, merge this into mcpServers, then fully quit and reopen Claude Desktop.

We couldn’t confirm it starts correctly

We ran the install command but it didn't respond within our test window — this can mean a slow first-time install rather than a real problem.

npx -y @kitewright/mcp

Process exited before answering initialize.

This is an experimental automated check and can have false negatives — missing environment variables, a slow cold install, etc. It doesn’t necessarily mean something’s wrong. Last checked 14d ago.

Overview

Tools21

What Kitewright lets your agent do. Expand a tool for its parameters.

Self-reported~62 tokens of context

Security & health

What it can reach and how reliably it runs — from our own checks, not the maintainer’s claims.

ActiveLast checked 3d ago

Recent health check succeeded.

11/11 checks healthy over the last 57d

Supply-chain signal

No high-severity advisories surfaced by our automated scan.

Critical 0High 0Medium 0Low 0

Scanned 13d ago via OSV.dev · @kitewright/mcp (npm)

Adoption & maintenance

Factual signals from GitHub, npm, and our automated checks — not a rating.

GitHub stars24Stargazers on the source repository.
npm downloads258Package downloads in the last 30 days.
Last commit20d agoMost recent push to the default branch.
Install checkInconclusiveDidn't respond in our test window — often a slow first install.
Tools exposed21Callable tools this server registers over MCP.

From the project README

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.

Kitewright demo — starts in 75 ms, ~8 MB idle, a real MCP endpoint, one-line install

Install in one line:

Terminal
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):

@playwright/mcpKitewright
Cold start → listening354 ms75 ms
Server RSS (idle)102–125 MB7.6 MB
Server RSS (after work)93 MB10.9 MB
Distribution18 MB pkg + Node.js runtime6.9 MB static binary
First navigate (incl. browser launch)2623 ms822 ms (session pre-warming)
Warm navigate latency80–116 ms99–105 ms (tie)
Idle behaviorbrowser kept alivebrowser reaped after idle TTL, pre-warmed again on next session

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

Code
crates/
├── engine/    kitewright-engine — CDP core (chromiumoxide): lazy launch, idle reaper,
│              per-session browser contexts, capped text extraction + AX snapshots.
│              Shared by all frontends.
└── server/    kitewright — rmcp Streamable HTTP server exposing the engine as MCP tools.
bindings/
└── node/      @kitewright/node — napi-rs bindings exposing a Puppeteer-compatible
               (experimental) API over the same engine (built separately; kept out
               of the core cargo workspace). See "@kitewright/node" below.

Each MCP session owns one persistent page inside its own Chromium browser context (cookie isolation between agents): log in once, keep clicking. The page and context are closed when the session ends; the browser itself is still reaped after the idle TTL and transparently relaunched on the next call.

Install

The zero-install way — run it straight from npx, like @playwright/mcp:

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

npx @kitewright/mcp resolves the prebuilt kite binary for your platform (an optional per-platform dependency, esbuild-style) and starts a stdio MCP server — no Rust toolchain, no build. See npm/kitewright-mcp.

Prefer the raw kite binary? (npx above is the easy path; these need a Rust toolchain.)

bash
# From the public repo — builds + installs the `kite` binary:
cargo install --git https://github.com/kitewright/kitewright kitewright   # → ~/.cargo/bin/kite

# From a local checkout:
cargo install --path crates/server

# Docker (headless Chromium bundled in the image):
docker run --rm -p 8090:8090 kitewright   # build locally: docker build -t kitewright .

Not yet published to crates.io or Homebrew — cargo binstall/brew aren't wired up. Use npx @kitewright/mcp (no toolchain) or the cargo install --git line above.

Get a browser

Kitewright drives Chromium over CDP but does not embed one. It uses a system Chrome/Chromium when present, honors BROWSER_EXECUTABLE, and — if neither is found — falls back to a browser downloaded by kite install:

bash
kite install    # fetch the latest stable chrome-headless-shell into the kite cache

kite install downloads the current Chrome-for-Testing chrome-headless-shell build for your platform into $KITE_CACHE_DIR (or the OS cache dir) and the engine picks it up automatically — no BROWSER_EXECUTABLE needed. Re-running is a no-op once a build is present. The Docker image already ships Chromium.

Run & connect

kite with no arguments serves MCP over Streamable HTTP (networked, default, supports auth + many sessions); kite --stdio serves a single session over stdio for local clients.

bash
kite
# → kitewright listening on http://0.0.0.0:8090/mcp

HTTP transport — connect from Claude Code:

Terminal
claude mcp add kite --transport http http://localhost:8090/mcp

stdio transport — MCP client config (Claude Desktop, Cursor, …):

config.json
{
  "mcpServers": {
    "kite": {
      "command": "kite",
      "args": ["--stdio"]
    }
  }
}

Configuration

Env varDefaultMeaning
MCP_HTTP_BIND0.0.0.0:8090Listen address
MCP_AUTH_TOKENunsetWhen set, /mcp requires Authorization: Bearer <token> (401 otherwise). Unset = open access + startup warning
MCP_RATE_LIMIT_PER_MINUTE300Per-client-IP request limit (fixed 60s window); 429 when exceeded
BROWSER_EXECUTABLEauto-detectPath to chrome / chromium / chrome-headless-shell. When unset: a system Chrome/Chromium is detected, else a kite install-managed build in the cache dir
BROWSER_NO_SANDBOXunsetSet (any value) to pass --no-sandbox (containers)
KITE_HEADLESSunsetKite launches a headed (visible) browser by default so you can watch automation. Set (any value) to run headless — required on servers, CI, and containers with no display, where a headed Chrome fails to launch
KITE_IDLE_TIMEOUT_SECS1800Idle seconds before a headless browser is reaped to free memory. Default 30min keeps a session alive across normal pauses (headed never reaps). A reap that does happen is recovered by cookie auto-restore, so an authenticated session survives it. Lower it on a memory-constrained multi-session server
KITE_ALLOW_SECRET_FILESunsetSet (any value) to let browser_fill_secret read file:/path secrets from disk. Requires KITE_SECRET_DIR (the directory reads are fenced to) so arbitrary host files can't be read/exfiltrated. env: secrets need no opt-in
KITE_VIEWPORT1440x900Default viewport / window size as WIDTHxHEIGHT (Chromium's own default is a cramped 800x600). Adjust at runtime with the browser_resize tool
MCP_CONTEXT_POOL2Number of pre-warmed blank browser contexts kept ready so a new session gets an instantly-usable context+page (zero context-creation latency). 0 disables. The pool refills in the background and drains with the browser on idle-reap (it never keeps the process alive)
KITE_CACHE_DIR<tmp>/kitewright-cacheShared on-disk HTTP cache (--disk-cache-dir), stable across launches so repeat asset fetches hit cache. NOTE: per-session isolated contexts (cookie isolation) use an ephemeral cache; this benefits the browser's default context
KITE_PREWARM_URLunsetIf set, prewarm navigates a throwaway page to this origin to establish DNS+TLS+connection before the first real navigate. No-op when unset
BROWSER_PREWARMunsetSet (any value) to launch + pre-warm the browser at server boot (otherwise prewarm fires when an MCP session initializes)
RUST_LOGinfoLog filter

Security

Kitewright drives a real browser, so treat the endpoint as privileged. The defaults are safe for local use; harden before exposing it.

Reviews

No reviews yet — be the first to share how it worked for you.

Frequently Asked Questions about Kitewright

kitewright/kitewright is an MCP server that provides lightweight browser automation for AI agents through navigate, screenshot, extract, and PDF capabilities. It runs as a single small binary and supports Streamable HTTP and stdio. It uses Chromium via CDP, with prewarming and lifecycle management aimed at reducing startup and idle resource costs.

Install it as an MCP server with `claude mcp add kitewright -- npx -y @kitewright/mcp`. This command lets Claude launch Kitewright through the provided package.

Kitewright provides navigation, screenshots, content extraction, and PDF capabilities. Its interaction automation also supports actions such as clicking, typing, filling forms, selecting options, and hovering.

Yes, Kitewright automatically waits for actionable elements before clicking, typing, filling forms, selecting options, or hovering. It checks that an element is present, visible, enabled, uncovered, and geometrically stable, then reports cause-specific errors when an action cannot proceed.

Kitewright supports both Streamable HTTP and stdio MCP transports. It can therefore be connected through a local process or an HTTP-based MCP endpoint.

Related MCP servers

Add a badge to your READMEShow it’s listed — live SVG, Markdown or HTML.

AllMCPs Directory Badge

Full Badge Customizer

Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.

Badge Style:
Live Dynamic SVG PreviewKitewright AllMCPs Directory Badge
Markdown (GitHub README)
[![AllMCPs](https://allmcps.com/api/badge/mcp-303?style=directory)](https://allmcps.com/mcp/mcp-303)
HTML Embed
<a href="https://allmcps.com/mcp/mcp-303"><img src="https://allmcps.com/api/badge/mcp-303?style=directory" alt="Kitewright on AllMCPs" /></a>