Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
The deterministic attack-surface perception layer for AI security agents
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.
Du brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Öffne Claude Desktop → Settings → Developer → Edit Config und füge dies in claude_desktop_config.json ein
{
"mcpServers": {
"zerodom": {
"command": "npx",
"args": [
"-y",
"@vexralabs/zerodom"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add zerodom -- npx -y @vexralabs/zerodomIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"zerodom": {
"command": "npx",
"args": [
"-y",
"@vexralabs/zerodom"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"zerodom": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@vexralabs/zerodom"
]
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
Dieser Server läuft auf deinem Computer, und ChatGPT kann sich nur mit Servern im Internet verbinden. Wähle eine andere App.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
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 6. Nov. 2026
Der Registry-Name wurde mit dem GitHub-Konto DevHusnainAi 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.1.5) kam vor 4 Tagen in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Python (uv), Node.js auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, Safe Fetch
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
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
MCP server for fetching URLs, safe against SSRF, DNS rebinding, and redirect-to-internal attacks.
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.
ZeroDOM drives your real, logged-in browser as two identities, replays the same requests as each, and flags where one user reaches what another can't — IDOR / broken access control, caught deterministically. Open-core, runs local, no account, no API key, nothing leaves your machine.
Under the hunt is a deterministic, token-lean perception engine for AI agents — the same core powers scan , crawl and any browser-driving task. IDOR is just where it bites hardest.
[Site](https://zerodom.vexralabs.com) · [Docs](https://zerodom.vexralabs.com/docs) · [Playground](https://zerodom.vexralabs.com/playground) · [Discord](https://discord.gg/tVRznUb5Ez) · [Quickstart ↓](#quickstart)
A normal user is denied the admin console (401) — then walks in by flipping one client-controlled cookie. ZeroDOM proves it: same request, two identities, 401 vs 200 . Full recording (mp4) .
compare & sweepTwo audiences, one engine:
scan --js adds DOM-XSS sinks, the callable API surface and header posture; repeat / probe / race turn recon into verification (Repeater, mass-assignment diff, and a TOCTOU burst).aria_snapshot, with handles that resolve 1:1 and don't drift when the page re-renders.Broken access control is the #1 web vulnerability (OWASP A01) and the one automated scanners miss — because catching it means knowing *who should be allowed to do what*, not just fuzzing one session. The usual answer is a human in Burp, clicking through the app as one user, then again as another, diffing by eye.
ZeroDOM does that mechanically. Give it two logged-in sessions; it replays the same request as each and reports the deterministic tells:
200, the other 401/403 on an identical request. If the only difference between them is client-controllable (a cookie, header or param), that's broken access control.No LLM guessing, no "the AI thinks maybe." ZeroDOM surfaces the tell with the exact replay that proves it — a reviewable diff you drop straight into a bug report. You confirm the bug.
It drives your real Chrome (relay mode) over chrome.debugger, so your cookies, MFA and SSO are already done — or a throwaway browser (--stealth) if you'd rather not touch your session. Either way the page's markup never leaves your machine, and it's read-only by default: destructive actions and out-of-scope hosts are refused.
It works equally well as a one-line CLI, a recon pipeline stage, or a native tool an
AI agent drives through MCP. Same deterministic primitives, three front doors.
See it run in 10 seconds — no account, no browser download (bare zerodom is a static fetch, no Chromium needed):
pip install zerodom # or: uvx zerodom · npm i @vexralabs/zerodom
zerodom https://news.ycombinator.com # the interaction graph + a token report
That's the perception engine — a flat, 1:1-addressable graph instead of 12k tokens of HTML.
Now the flagship — find an IDOR. Save two logged-in sessions as Playwright storage_state files (one per account), then diff a protected endpoint across both:
zerodom compare https://app.example.com/api/admin/dashboard \
--as user=user.json --as admin=admin.json
{
"identities": { "user": { "status": 401, "bytes": 2616 }, "admin": { "status": 200, "bytes": 3469 } }, "only_admin": ["Manage users", "Billing & plans", "Overview"], "note": "admin authorized (200) where user denied (401) — broken access control if the only difference is client-controllable" }
That's the whole loop: same request, two identities, a 401-vs-200 split → a lead to confirm. only_admin lists the privileged controls the normal user should never see.
Don't have storage-state files? Capture one with context.storage_state(path="user.json") in Playwright, or export cookies from a logged-in session. Want the whole app, not one URL? → zerodom sweep.
compare & sweepzerodom compare — one endpoint, across identitiesFetch one URL under each saved session and diff the responses. Byte-identical content across two users on a private resource is a cross-tenant IDOR; a 401-vs-200 split is a broken boundary. only_ lists the actionable nodes each identity sees that the other doesn't.
# Sweep a range of object ids through two identities:
seq 1 500 | sed 's#^#https://app.example.com/api/invoice/#' \ | zerodom compare - --as alice=alice.json --as bob=bob.json \ | jq 'select(.identical_body_pairs | length > 0)'
zerodom sweep — the whole app, one commandcompare tests one URL. `sweep` does the entire app: it crawls as one identity to map the GET surface (pages + the API calls the JS fires), then replays every in-scope URL under *all* your identities and reports only the deterministic tells.
zerodom sweep https://app.example.com --as user=user.json --as admin=admin.json --format md
| severity | rule | url |
| -------- | ---------------------- | ------------------------------------- | | medium | access-boundary-split | https://app.example.com/api/admin/... |
Read-only throughout: only GET is replayed, destructive URLs are dropped (--deny). --format md emits a report-ready table (default is JSONL). This is the "point it at an app with two logins and it finds the broken access control" pass.
Both take --proxy (route through Burp/Caido), --header (a program's WAF-bypass token), and a scope you can lock. Challenge pages (Cloudflare / Turnstile / reCAPTCHA / hCaptcha) are detected and climbed by a scope-gated clearance ladder; a wall nothing clears is reported as an honest blocked, never worked around outside an authorized target.
repeat / probe / raceMapping an app surfaces the endpoints; these verbs act on them. repeat is a Repeater over the session (--save writes HAR/.http evidence for a report). probe replays an endpoint with a tampered body and diffs it against the baseline — an accepted, reflected field is a mass-assignment lead. race fires a concurrent burst (one body, or a mix of operations via repeated --body) to flag a check-then-act race (TOCTOU); the stdlib engine is always available, and --engine http2 multiplexes the burst over one connection via the optional zerodom[race] extra.
zerodom race https://app.example.com/api/coupon --body '{"code":"SAVE20"}' -n 30 \
--setup setup.json --check https://app.example.com/api/cart
All three are exposed to agents over MCP as zerodom_repeat / zerodom_probe / zerodom_race.
Standard MCP browser tools hand the model raw pixels (slow, stale on scroll) or an accessibility tree (no stable handles — repeated controls collide). zerodom-mcp gives your agent a flat, token-frugal graph where every click [45] resolves deterministically over CDP to exactly one element — and the same tools do cross-identity IDOR hunting the others can't. Why ↓
ZeroDOM is a native MCP server, so Claude, Cursor or any MCP agent can hunt with the same primitives. Run zerodom setup for a guided first-run (checks Chromium, prints the extension path + chrome://extensions steps, emits the config below, reports relay reachability — print-and-guide, no account, nothing leaves your machine).
// Claude Desktop: claude_desktop_config.json · Cursor: .cursor/mcp.json
{ "mcpServers": { "zerodom": { "command": "uvx", "args": ["--from", "zerodom", "zerodom-mcp"] } } }
Once before first use (so the server never downloads mid-tool-call): uvx --from zerodom playwright install chromium.
Using LangGraph, CrewAI, OpenAI Agents SDK, Pydantic AI, LlamaIndex, Google ADK or AutoGen? Ready-to-run MCP examples — same server, a few lines each — are in examples/integrations/.
The full tool set (click to expand)
| tool | what it does |
|---|---|
zerodom_parse_url(url, verbose=False, frames=False, viewport_only=False, check_occlusion=False) | navigate, return the compact graph; frames=True also reads same- and cross-origin iframes (auth portals, payment fields) |
zerodom_read_page(verbose=False) | re-read the live DOM without navigating |
zerodom_find(query) | return only the nodes matching a phrase |
zerodom_click_node(node_id) | click, then return what changed — flags a same-page no-op shortly after navigation as a possible hydration miss |
zerodom_fill_node(node_id, text) | type via real keystrokes — works in contenteditable editors (Notion, Slack, Discord, Jira) |
zerodom_hover(node_id) | hover, revealing hover-triggered menus/tooltips |
zerodom_press_key(node_id, key) | press a key on a focused node (Enter, Escape, Tab, …) |
zerodom_upload_file(node_id, path) | set a file input's value to a local path |
zerodom_drag(source_node_id, target_node_id) | drag one node onto another |
zerodom_scroll(direction, amount=800) | scroll, return what's newly visible |
zerodom_new_tab(url=None) | open a tab and make it active |
zerodom_list_tabs() | list every open tab, marking the active one |
zerodom_switch_tab(tab_id) | make another open tab active |
zerodom_close_tab(tab_id=None) | close a tab (the active one by default) |
zerodom_screenshot(path=None) | full-page screenshot of the active tab, saved to disk |
| `zerodom_set_viewport(wi
Nur der Anfang wird gezeigt; den Rest findest du im Repo