Browser Use
Browser agents and stealth cloud browsers for AI: run web tasks, fill forms, extract data.
Beschreibung vom Entwickler (englisches Original)
Sandboxed computer-use for AI agents: drive real browser + desktop apps in nested X11 windows
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Der Entwickler hat in der Registry keine Installationsangaben gemacht. Sieh dir unten die README des Entwicklers an.
Läuft auf deinem Computer; die Tool-Liste erscheint nach der Installation in deiner KI-App.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 7. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto segentic-lab bestätigt, dem das Repo gehört
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieser Server läuft auf deinem Computer; es gibt keinen Endpunkt im Internet
Läuft auf deinem Computer und nutzt stattdessen lokale Einstellungen
Läuft auf deinem Computer; Tool-Listen können wir nur von Endpunkten im Internet lesen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft auf deinem Computer. Deine KI-App startet ihn bei Bedarf, und die Daten laufen nicht über die Server des Entwicklers (außer der Server ruft selbst einen Onlinedienst auf).
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (0.3.0) kam vor 6 Tagen in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code.
In derselben Kategorie: Browser Use, Chrome DevTools MCP, MCP Server Browser
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
Browser agents and stealth cloud browsers for AI: run web tasks, fill forms, extract data.
MCP server for Chrome DevTools
MCP server for browser use access
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
A sandboxed computer-use MCP server — let an AI agent drive a real browser and desktop apps (mouse, keyboard, screenshots, clipboard, vision grounding), confined to a nested X11 window so its input and vision never touch your real screen or the windows of your other apps.
Like a lab glovebox: the agent reaches in and manipulates real applications, sealed off from your desktop. Bring the sandbox up, log into whatever sites or apps you want to automate *inside that window*, and the agent operates only there — you can watch it live and close it instantly.
Speaks the Model Context Protocol, so it works with MCP clients
like Claude Code. Your host can run Wayland; the sandbox gives the agent a real X server to drive.
An agent driving a real browser in the sandbox — gliding the cursor, inserting a unicode name (Nadja Kovačič), typing, and submitting. All confined to a nested X11 window.
DISPLAY :1). Everything the agent does — clicks, typing, screenshots — is confined to that window, not your real desktop.pkill Xephyr to close everything.The isolation is display-level (see Safety): the apps themselves run as your user with your filesystem. For OS-level isolation run glovebox inside a VM or container.
uv (used for the virtualenv).xserver-xephyr (Xephyr), openbox, scrot, x11-utils, xdotool, wmctrl, xclip (+ tesseract-ocr for basic). On Debian/Ubuntu the installer auto-installs them via apt (sudo); on Fedora/Arch it prints the matching dnf/pacman command. The MCP server itself is distro-agnostic — any Linux with these tools works. openbox is not optional in practice: without a window manager Xephyr ignores synthetic pointer motion, so clicks would land in the screen center (launch_app warns when it is missing).local vision mode. The server checks this itself (status() → vision.gpu) and auto falls back to basic/none when it is not met.Pick a vision backend and run its one-liner (clone → install). Each one installs the system packages (auto via apt on Debian/Ubuntu) and the Python deps for that mode, and writes a ready-to-paste mcp-config.json with your paths.
`none` — no local models; your agent reads screenshots itself (lightest, instant):
git clone https://github.com/segentic-lab/glovebox-mcp && cd glovebox-mcp && ./install.sh none
`basic` — Tesseract OCR grounding (parse_screen → text lines + coordinates, CPU-only):
git clone https://github.com/segentic-lab/glovebox-mcp && cd glovebox-mcp && ./install.sh basic
`local` — OmniParser on an NVIDIA GPU (parse_screen → text + icons, pixel-precise; ~4 GB weights, ≥6 GB VRAM):
git clone https://github.com/segentic-lab/glovebox-mcp && cd glovebox-mcp && ./install.sh local
Your choice is written to .vision-mode (override per run with the GLOVEBOX_VISION env var). Without either, the server runs in `auto` and picks the best backend that is actually usable. python vision.py check prints the same diagnosis status() returns (GPU, weights, tesseract).
Claude Code, Cursor, Codex, or your own agent — it's a standard MCP server, not tied to any one host. Two compatibility notes: `basic`/`local` return element coordinates as text, so they work even with text-only agents; `none` relies on the client passing the tool's screenshots to a multimodal model (fine for Claude Code, Cursor, and other image-capable MCP clients). In any mode, clipboard() gets exact text out of an app without vision at all.
./start-display.sh # 1440×900 Xephyr window with a browser
./start-display.sh 1920x1080 # …or pass a screen size (or set $RES)
Log into any sites or apps you want to automate **in that window**.
install.sh already wrote `mcp-config.json` with your real install path — copy its glovebox block into your client's MCP config: { "mcpServers": { "glovebox": {
"command": "/abs/path/to/glovebox-mcp/.venv/bin/python", // filled in by install.sh "args": ["/abs/path/to/glovebox-mcp/server.py"], "env": { "DISPLAY": ":1" } } } }
Restart the client so it loads the server.
:1 window.Driving it with an AI agent? Paste
AGENTS.mdinto the agent's system prompt — it
teaches the observe → act → verify loop, grounding, the upload/unicode gotchas, and when to stop.
| Tool | What | |
|---|---|---|
status() | Server + sandbox status in one read-only call: version, the vision diagnosis (requested vs. effective backend and *why*, GPU name/VRAM, OmniParser code/weights, tesseract languages), live instances, and which system deps are present. Run it first — and paste it into bug reports. | |
screenshot(instance, region?, scale?, format?) | [json, image]. region="x,y,w,h" zooms into a rectangle, scale=0.5 shrinks, format="jpeg" compresses — cut payload or read small text. | |
parse_screen(instance, granularity?) | Vision grounding → JSON of detected elements (id, type, label, interactive, pixel-center; capped at 300 per call, flagged via "truncated") + a numbered Set-of-Mark image. basic merges OCR words into lines ("Sign in" = one target; granularity="word" for single words). | |
click_element(id) | Click an element from the last parse_screen (no coordinate guessing). | |
click(x,y) · double_click · move_mouse · scroll · drag(…, steps?) | Pointer ops. Coordinates outside the display are rejected (xdotool would silently clamp them). drag emits intermediate motion events so canvases and sliders register it. | |
type_text(text) | Unicode-safe typing (ASCII via xdotool; anything with č/š/ž… is inserted via the clipboard, because xdotool's synthetic unicode is silently dropped by some GTK apps). | |
press_keys("ctrl+a" / "Return" / "ctrl+a Delete") | Keys, combos, and space-separated sequences (xdotool syntax). Invalid names error — nothing is pressed. | |
| `clipboard(action="get"\ | "set", text?)` | Read the instance's clipboard (select + ctrl+c, then read exact text — no OCR) or set it (then ctrl+v). Per-instance. |
wait_for_stable(instance, timeout_ms?, threshold?) | Wait until the screen stops changing (page loaded, app drew) instead of guessing a delay. Reports stable/timed_out honestly. | |
window_info(instance) | Active window title + geometry and the visible windows — confirm navigation or that an app opened, without an image. | |
upload_file(filepath, selector?, page_url_contains?) | Attach a local file to a page's via the Chrome DevTools Protocol. The nested X11 file picker is invisible to automation and hangs the renderer, so use this for all uploads — never click an upload button expecting a dialog. Works on Chromium-family browsers started by launch_app/start-display.sh (per-instance --remote-debugging-port, 9222+N). Browser file inputs only — for native apps see open_file. | |
open_file(filepath, app?) | Open a local file in a native app on the instance's display (e.g. app="gimp") or via xdg-open. Fails honestly if the handler exits immediately (no app registered for that type). | |
list_files() | The instance's staging folder files/ / + entries with size, mtime and a partial flag for in-progress downloads. | |
app_log(instance, lines?) | Tail of the launched app's stderr — read it when an app crashed or drew nothing. | |
launch_app(command, name?, size?) · list_instances() · close_instance(n) | Multi-instance control (see below). | |
wait_ms(ms) · get_screen_size() | Timing / sandbox size + effective vision backend. |
Every control tool takes `instance=N` and optional `observe` / `settle_ms` (see below). In local mode OmniParser is lazy-loaded on first parse_screen (~6 s once, then ~2 s/parse), after a GPU preflight (VRAM present and free).
Every tool returns JSON: {"ok": true, "action": "click", "instance": 1, "detail": "clicked (10,20) button 1", …}. Failures come back with the MCP isError flag set and the same JSON shape embedded in the error text — {"ok": false, "error": "…", "fix": "…"} — where `fix` names the call that unblocks you (e.g. a click on a dead instance says to run list_instances() / launch_app(); an unknown element id says to re-run parse_screen(); a GPU that is too small says which mode to switch to). Silent no-ops are treated as failures too: an invalid keysym, a zero scroll, an off-screen click, closing an instance that isn't running, an app that exits on launch, or non-ASCII typing without xclip all error instead of pretending success. Clamped waits are flagged (clamped / settle_clamped). Image-returning calls (screenshot(), observe="screenshot"|"parse") return [json, image]. No subprocess can hang a call: xdotool/xdpyinfo/xclip run under timeouts and a frozen display is reported as such.
GLOVEBOX_VISION env var, or the .vision-mode file, or default `auto`:
| Mode | parse_screen | Needs | When |
|---|---|---|---|
auto | the best ready backend below (local → basic → none); status() says which and why | — | default |
none | disabled (returns a note) — use screenshot() + reason, clipboard() for exact text | nothing (mcp, mss, xdotool) | lightest; let the agent's own vision do grounding |
basic | Tesseract OCR → text lines + coords (+ confidence) | tesseract-ocr + pytesseract | no GPU; text-only grounding |
local | OmniParser → text + icons + coords | torch + CUDA + OmniParser weights + NVIDIA GPU ≥ 6 GB | best grounding |
In local mode the models are loaded by one shared vision-service process per machine (vision_service.py), not by every agent's server: the first parse_screen starts it, parallel agents queue on it (queued_ms in the result), and it exits after 15 idle minutes so a forgotten service never pins the GPU. If it can't be reached the server loads the models in-process instead — the service is an optimization, never a new failure mode. status() shows it under vision.omniparser.service; python vision_service.py status|stop from the shell.
An explicitly requested basic/local that is not usable fails `parse_screen` with the fix named (OmniParser not installed, no/too-small GPU, GPU out of memory, missing tesseract language data) — it never silently falls back; only auto does, and it says so. Tesseract languages default to slv+eng filtered to what is installed (GLOVEBOX_TESS_LANG overrides). Switch anytime with ./install.sh (installs only what that mode needs).
Every control tool takes `instance=N` (default 1 = the start-display.sh sandbox). Sp
Nur der Anfang wird gezeigt; den Rest findest du im Repo