react-native-dev-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| doctorA | Check the health of the React Native development environment: detected OS, iOS/Android toolchains, Metro status and project info. Call this first when something is failing or before device/build operations. |
| list_runtime_targetsA | List debuggable React Native runtimes exposed by Metro. Call when a runtime tool reports TARGET_AMBIGUOUS or to check what is connectable. Requires Metro running. |
| read_consoleA | Read console logs from the running React Native app (buffered since the runtime bridge connected). Cursor-based: pass the previous nextCursor to read only new entries. Requires Metro running. |
| evaluate_jsA | Execute a JavaScript expression inside the running React Native app and return the result. Use to inspect state (Redux/Zustand stores, globals) or trigger behavior. Promises are awaited via polling (Hermes limitation), up to timeoutMs. This can mutate app state — prefer read-only expressions when verifying. Requires Metro running. |
| reload_appA | Trigger a full JS reload of the running React Native app (same as pressing 'r' in the Metro terminal). Requires Metro running. |
| run_buildA | Start a native build (Gradle) in the background and return a job id immediately. Poll with get_build_status. Use after native-layer changes; for pure JS changes prefer reload_app. |
| get_build_statusA | Check a build job started by run_build. Long-polls up to waitSeconds (default 25) so you can wait efficiently; on completion returns structured diagnostics with probable causes and suggested fixes. |
| cancel_buildA | Cancel a running build job (kills the whole process tree). |
| parse_build_logA | Parse a native build log (xcodebuild, Gradle, CocoaPods, Metro) into structured diagnostics with probable causes and suggested fixes. Use on logs from terminals, CI, or a logPath from get_build_status. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool has a distinct purpose: doctor checks environment health, evaluate_js/read_console/reload_app interact with running app, run_build/get_build_status/cancel_build/parse_build_log handle builds, and list_runtime_targets discovers runtimes. No significant overlap.
Most tools follow a clear verb_noun snake_case pattern (e.g., cancel_build, evaluate_js, get_build_status). The exception is 'doctor', which is a single word noun used as a command, but it's a standard term in React Native CLI.
With 9 tools, the set is well-scoped for React Native development. It covers build management, runtime interaction, diagnostics, and health checks without being overwhelming or sparse.
The tool surface covers the core development loop: build, status, parse logs, cancel, reload, inspect state, read console, health, and runtime discovery. Minor gaps like explicit device running or Metro starting are likely out of scope.