Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Drive a running React Native or Expo app from inside its JS runtime: see, act, prove.
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": {
"rn-devtools-hub": {
"command": "npx",
"args": [
"-y",
"rn-devtools-hub",
"mcp"
]
}
}
}Führe das in deinem Terminal aus
claude mcp add rn-devtools-hub -- npx -y rn-devtools-hub mcpIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"rn-devtools-hub": {
"command": "npx",
"args": [
"-y",
"rn-devtools-hub",
"mcp"
]
}
}
}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": {
"rn-devtools-hub": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"rn-devtools-hub",
"mcp"
]
}
}
}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 rn-devtools-hub 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.22.0) kam vor 2 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Außerdem brauchst du Node.js auf deinem Computer.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, AI Deprecations
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.
AI model shutdown dates, replacements, change feed and webhook alerts for 8 providers.
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.
rn-devtools-hub
The agent runtime for React Native. Your agent sees the app the way React sees it, knows which file produced each element, acts without coordinates, and proves that it works. Zero dependencies, no telemetry or usage counting, with a local hub and SDK.
Documentation · Quick start · Integration · Contributing
Both plugins install the MCP server plus a skill that teaches the agent to chain its tools: check the project context before debugging anything that looks impossible, prove results with assertions instead of screenshots, wait on events instead of sleeping, and read an element's source instead of grepping the repository.
Claude Code
/plugin marketplace add rn-devtools-hub/rn-devtools-hub
/plugin install rn-devtools-hub
Codex
codex plugin marketplace add rn-devtools-hub/rn-devtools-hub
codex plugin add rn-devtools-hub
Then start the hub at the root of your app, which is what the agent talks to:
npx rn-devtools-hub
Registering the server by hand works too. Claude Code:
claude mcp add rn-devtools --transport http http://127.0.0.1:8973/mcp
Codex, in ~/.codex/config.toml:
[mcp_servers.rn-devtools]
url = "http://127.0.0.1:8973/mcp"
Cursor has no marketplace, so it is two files in your own project. Declare the server in .cursor/mcp.json:
{
"mcpServers": { "rn-devtools": { "type": "http", "url": "http://127.0.0.1:8973/mcp" } } }
And copy the rule, which is the Cursor equivalent of the skill:
mkdir -p .cursor/rules
cp node_modules/rn-devtools-hub/templates/cursor-rule.mdc \ .cursor/rules/rn-devtools-hub.mdc
It ships with alwaysApply: false, so Cursor pulls it in when the task matches instead of paying for it on every request.
For any other agent, the skill on its own comes from the skills.sh registry:
npx skills add rn-devtools-hub/rn-devtools-hub
It writes .agents/skills/rn-devtools-hub and links it into whichever agents it detects, from Gemini CLI and Copilot to Windsurf and Zed. This installs the skill only, so register the server as above and start the hub to give the agent something to talk to.
Any client that speaks only stdio uses npx rn-devtools-hub mcp, which bridges to the hub and starts it on demand.
When a testing or debugging task starts, the agent is instructed to announce the project and its clickable dashboard URL, then continue automatically. The hub supplies the actual bound port and current token, including when a second project uses a fallback port. The link is also available in the dashboard field of list_devices, get_project_context and session_start.
Overview: request counts, error rate, JS thread lag, connection and device at a glance
Network: colored methods, slow requests highlighted, foldable JSON, copy as cURL, secrets redacted before they leave the device
Mirror: the live device screen over adb, click to tap, drag to swipe, wheel to scroll, plus Back/Home/Recents/Dev menu
Tools: what the agent did and what the app did back, calls per tool split into answered / empty / failed, failures grouped by message, empty answers with the reason the tool gave, and the context each answer bills the agent
The SDK lives inside the JavaScript runtime of your app.
The SDK executes directly alongside your application code. It reads React's tree, invokes handlers, instruments requests and reaches registered stores through APIs installed inside the app. The hub receives these capabilities over its own local connection, without requiring a debugger protocol session. Other tools can access runtime internals through protocols such as CDP; the hub's foundation is an explicit in-app SDK and its event contracts.
That position is what the whole product is built on. Everything else follows from it:
| The agent can | Because it is inside the runtime |
|---|---|
| Find an element by role and accessible name, then act on it | Actions go through the app's own props, not through pixels |
| Get the file and line that produced an element | The location lives in React's dev bookkeeping |
| Prove a step without a screenshot | A screenshot cannot show a request that failed silently |
| Tell a stale native build from a code problem | Only the runtime knows what the binary actually is |
| Freeze the clock and the network | Date and fetch are in the runtime |
| Put the app in an exact state without walking ten screens | Stores are reachable directly |
| Explain a visual regression, not just score it | The changed region maps back to the component that owns it |
A pure JavaScript SDK in the app (inert in production), a local hub in a single process, a dashboard in the browser. Zero dependencies anywhere, including the hub. The hub has no telemetry. MCP results are delivered to your agent and may be sent to its model provider. Configured store plugins contact their declared vendor endpoints.
| Panel | What you see |
|---|---|
| Overview | KPI tiles, JS thread lag, HTTP statuses, duration distribution |
| Crashes | Fatal errors, JS errors, unhandled promise rejections, stacks |
| Network | Request/response inspector (colored methods, durations, sizes), copy as cURL, secrets redacted |
| Uploads | Live upload queue (if your app emits the events, see the protocol) |
| Cache | React Query snapshot: keys, statuses, freshness, data |
| Storage | AsyncStorage keys, sizes, values, live write timestamps |
| Screens | Navigation journey, time spent per screen |
| Logs | console.log/info/warn/error, colorized JSON, filters |
| SQLite | Read-only SQL console (SELECT/PRAGMA) on your app's database |
| Endpoints | Map of declared endpoints, calls, latencies |
| Actions | Buttons driving the app: reload, clear caches, your custom actions |
| Tests | Human-readable .hubflow scenarios, live replay progress, failure diagnosis, approved visual evidence and safe target repair candidates |
| Tools | What the agents do with this hub: calls per tool, failures with their message, empty answers and why, context bytes returned (pixels counted separately, because a session spending most of its context on screenshots is a session verifying the expensive way), selectors used, and the loop replayed against the app's own events |
| Plugins | The services around the app: App Store Connect and Google Play, what each one is configured with, whether it may change a release, and every host it will contact |
| Design | Icon, splash, fonts, sounds, identity (read from app.json and the assets) |
| Mirror | Live app screen (needs react-native-view-shot in the app), full Android via adb (tap, swipe, keyboard, Wi-Fi), iOS simulator via xcrun |
The Overview panel opens with the project context: what the project declares, what the app actually runs, and whatever the two disagree on. A stale native build is the most common way to lose an afternoon here, and it is named before you start reading code.
Plus: multi-device with merged sessions, bug report export in Markdown (ready for a GitHub issue), real-time capability badges, and a local MCP server to drive everything from Claude, Cursor or any MCP client.
See Hubflow scenarios to record an exploration, save it as a runtime regression test, replay it in CI and inspect its selected success or failure screenshots in the dashboard.
| Tool | What it answers |
|---|---|
get_project_context | What the project declares, what it actually runs, and the contradictions. Call it first when anything behaves impossibly |
get_ui_tree, query_ui | The visible components, each carrying the source file and line that produced it |
ui_act | Tap, type, submit, scroll, by element and never by pixel |
assert | Proves a step: element kinds retry, event kinds catch a request that failed silently, a console error, an unhandled rejection |
freeze_time, mock_network | Deterministic at the JS level, so a scenario runs the same twice |
get_state, set_state | Put the app in an exact state without walking ten screens |
render_component | Mount a component inside the running app, under its real providers |
snapshot_baseline, compare_snapshot | A visual diff that names the component owning the changed region |
export_session, export_flow | One correlated timeline, and actions paired with the consequences they caused |
save_flow, list_flows, get_flow, run_flow, propose_flow_repair | Persist a runtime scenario, replay it with assertions and screenshots, and create a reviewable repair candidate when a strongly identified target moves |
audit_accessibility | What React renders but the accessibility tree does not expose |
list_plugins, asc_*, gplay_* | The release around the app: has the build finished processing, where is the version in review, what is production serving, what do the store reviews say. And driving it: distribute to TestFlight, submit for review, promote a track, widen or halt a staged rollout |
capture_store_screenshots | Regenerate the App Store and Play screenshots from the running app: devices, locales and screens from a manifest, each reached with the app's own dev actions, captured at native resolution and uploaded. The pixels never enter the agent's context |
Source locations survive React 19, where the location lives in owner stacks pointing into the bundle: the hub symbolicates them against Metro before the agent sees them.
For AI agents, the hub also exposes runtime UI automation over MCP: get_ui_tree (semantic tree of the visible components, read from the React runtime, including native views without accessibility like maps), query_ui (find elements by role and accessible name, testID, placeholder, text or label, scoped with within, with measured rects), ui_act (tap, type exact text, submit, scroll, all by element, never by pixels, and it reads the field back to say whether the text landed), typed dev actions (list_actions/run_action: navigate, seed, login without touching the UI), and a correlated event flow (wait_for_event, get_events_since) that replaces sleeps with real signals like screen.ready. Works in Expo Go, development builds and bare React Native, and in CI without any simulator: enable it with devtools.attachUiAutomation().
The hub covers the native layer too, as a superset of what idb/simctl scripting gives an agent: session_start boots a dev build on the right Metro server with zero dialogs (permissions pre-granted, dev-menu onboarding skipped), plus set_permission, launch_app, open_url, screenshot_native, set_location, send_push, set_appearance, set_animations, set_overlay (the expo-dev-menu bubble covers native controls no UI tree can show) and the last-resort tap_native and swipe_native, on iOS simulators and Android devices, with every capabili
Nur der Anfang wird gezeigt; den Rest findest du im Repo