Provides device control via adb: list/boot devices, install/launch apps, deep links, screenshots, and demo status bar.
Works with Expo-managed React Native projects, providing full tooling support.
Runs Gradle as a background job and parses build logs for diagnostics, returning structured error information.
Uses Hermes CDP protocol for runtime bridge to stream logs and evaluate JS.
Provides device control via simctl: list/boot devices, install/launch apps, deep links, screenshots, and demo status bar.
Connects to Metro's inspector to stream console logs and evaluate JavaScript inside the running app.
Targets React Native framework, providing development tools for device control, runtime inspection, and build diagnostics.
Allows inspecting Redux store state by evaluating JavaScript expressions inside the running app.
Runs xcodebuild as a background job and parses build logs for diagnostics, returning structured error information.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@react-native-dev-mcp Run my app on Android and figure out why it's broken at startup."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that gives AI coding agents hands, eyes and a mechanic's ear for React Native development.
Coding agents are good at writing React Native code and bad at everything around it: putting the app on a device, seeing what it logs, and understanding why the native build exploded into 4,000 lines of Gradle. This server closes that loop with three pillars:
Pillar | What the agent gets |
🤲 Device control | One uniform interface over |
👀 Runtime bridge | Connects to Metro's inspector (CDP/Hermes, RN 0.76+ "Fusebox"). Streams |
🔧 Build diagnostics | Runs |
Works with Expo and bare React Native CLI, RN 0.76+ (tested on 0.80+).
The server is environment-aware: on Windows/Linux, iOS tools are never even registered, and
every failure returns a structured remediation the agent can act on. Start with the
doctor tool.
Requires Node 22+. The server runs on your machine over stdio.
claude mcp add rn-dev -- npx -y react-native-dev-mcpOr per-project, in .mcp.json:
{
"mcpServers": {
"rn-dev": {
"command": "npx",
"args": ["-y", "react-native-dev-mcp"]
}
}
}In ~/.codex/config.toml:
[mcp_servers.rn-dev]
command = "npx"
args = ["-y", "react-native-dev-mcp"]Any MCP client that speaks stdio works — point it at npx -y react-native-dev-mcp.
Useful flags: --project-root <path>, --metro-port <port>, --eager-metro, --verbose.
Related MCP server: multivon-mcp
Once installed, talk to your agent in plain language — it picks the right tools:
"Run my app on Android and figure out why it's broken at startup."
"Boot an iPhone simulator, build and install the app, then screenshot the login screen."
"The iOS build is failing. Diagnose it, apply the suggested fix and rebuild until it's green."
"Watch the console while I tap through checkout and summarize any errors you see."
"What's in the Redux store right now? Read the auth slice from the running app."
"Open the deep link myapp://profile/42 and verify it lands on the right screen."
A typical agent session against a real app:
doctor → toolchains ok, Metro running, project: expo · RN 0.85
list_devices → iPhone 16 Pro (booted)
run_build {platform: "ios"} → job a1b2c3d4
get_build_status {jobId} → ❌ failed · "Sandbox not in sync with Podfile.lock"
→ fix: run pod install (tool run_pod_install)
run_pod_install → ✅
run_build → get_build_status → ✅ artifact: .../MyApp.app
install_app + launch_app → app running
read_console {level:"error"} → "TypeError: cannot read property 'id' of undefined"
evaluate_js {expression:
"globalThis.store.getState().auth"} → { user: null, … } ← found it
(agent edits code) → reload_app → read_console → clean ✅
take_screenshot → 📸 verified visuallyEnvironment · doctor
Devices · list_devices boot_device shutdown_device install_app uninstall_app launch_app terminate_app open_url take_screenshot set_status_bar_demo
Runtime · list_runtime_targets read_console evaluate_js reload_app
Build · run_build get_build_status cancel_build run_pod_install parse_build_log
Full reference with schemas and error codes: documentation site.
One debugger at a time (Hermes limitation). If React Native DevTools is attached, runtime
tools return DEBUGGER_OCCUPIED with instructions. Close the DevTools tab and retry.
Builds never block. run_build returns a job id in <2s; poll with get_build_status
(it long-polls up to 60s per call). Logs persist on disk and can be re-parsed any time with
parse_build_log.
Token-frugal by design. Lists are collapsed and capped, console reads are cursor-based and
deduped, build results carry at most 10 diagnostics plus a logPath escape hatch.
The easiest high-impact contribution is a build error signature — pure YAML plus a log
snippet, no TypeScript. See CONTRIBUTING.md. Development is spec-driven:
every tool's contract lives in specs/.
MIT © Luiz Esper
Cancel a running build job (kills the whole process tree).
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly mentions 'kills the whole process tree', which indicates the destructive nature beyond simply canceling. Since annotations only include openWorldHint: false, the description adds valuable behavioral context, though it could be more detailed about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and outcome, containing no superfluous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, output schema exists), the description is minimal but lacks guidance on using the parameter or interpreting the output. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'jobId' with 0% description coverage, and the tool description does not explain what jobId is or how to obtain it. The description adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Cancel' and resource 'a running build job', and clarifies the action with 'kills the whole process tree'. It clearly distinguishes from sibling tools like run_build and get_build_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or comparison with sibling tools like get_build_status for checking status before cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| projectRoot | No | Project root to inspect (default: server --project-root) |
| Name | Required | Description |
|---|---|---|
| ios | Yes | |
| host | Yes | |
| metro | Yes | |
| android | Yes | |
| project | Yes | |
| problems | Yes | |
| restartRequired | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only behavior, and the description adds context on what health checks are performed (OS, toolchains, etc.). No contradictions. Slight deduction for not detailing error behavior, but output schema likely covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and usage guidance. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the tool's diagnostic nature, the description adequately covers when to use and what is checked, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'projectRoot'. The description doesn't add new semantics beyond the schema, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks the health of the React Native development environment, listing specific components (OS, toolchains, Metro status, project info). This distinguishes it from sibling tools like run_build or evaluate_js.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'Call this first when something is failing or before device/build operations,' providing clear guidance on when to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | No | Runtime target id (from list_runtime_targets) | |
| timeoutMs | No | Promise wait budget (default 5000) | |
| expression | Yes | A JS expression (wrap multi-statement code in an IIFE) | |
| awaitPromise | No | Await a returned Promise via polling (default true) |
| Name | Required | Description |
|---|---|---|
| result | No | |
| preview | No | String preview when the value is not fully serializable |
| exception | No | |
| truncated | No | |
| resultType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool can mutate app state, that Promises are awaited via polling due to Hermes limitation, and the timeout behavior. Annotations provide little (openWorldHint: false), so the description carries the burden effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose. Each sentence adds value without redundancy. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage context (inspect/trigger), behavioral caveats (mutability, polling, Metro), and prerequisites. Output format is left to the output schema, which is acceptable. Everything needed for correct invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by explaining that timeoutMs limits Promise polling and that awaitPromise controls awaiting. This goes beyond the schema's bare descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'execute' and the resource 'JavaScript expression inside the running React Native app'. It distinguishes from siblings like list_runtime_targets or read_console by focusing on evaluating arbitrary JS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use: to inspect state or trigger behavior. It advises preferring read-only expressions when verifying, and notes the prerequisite 'Requires Metro running'. No exclusions or alternatives are given, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| waitSeconds | No | Long-poll budget (default 25) |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| logPath | Yes | |
| logTail | No | Last lines of the log — only when no signature matched a failure |
| exitCode | No | |
| elapsedMs | Yes | |
| errorCount | No | |
| diagnostics | No | |
| artifactPath | No | |
| logSizeBytes | No | |
| warningCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses long-polling behavior with configurable waitSeconds and returns structured diagnostics with causes and fixes. Annotations already indicate read-only, so description adds valuable behavioral context beyond safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, behavior, and output. Front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: purpose, polling, default, output format. Output schema exists for return values. Adequate for tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; jobId lacks description, but description implies it comes from run_build. waitSeconds default is noted. Description adds marginal value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Check a build job started by run_build', specifying the verb and resource. It distinguishes from sibling tools like run_build, cancel_build, and parse_build_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly ties usage to after run_build and mentions long-polling for efficient waiting. Does not explicitly exclude alternatives but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | Metro port (default: server --metro-port) |
| Name | Required | Description |
|---|---|---|
| targets | Yes | |
| metroPort | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it lists 'debuggable' runtimes and requires Metro, but doesn't elaborate on behavior like error handling or response format. Minimal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundancy. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema present, the description covers purpose and usage triggers completely. No gaps noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes the single parameter 'port' with full coverage (100%). Description does not add additional meaning beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists 'debuggable React Native runtimes exposed by Metro', specifying verb and resource. It distinguishes from siblings like run_build or reload_app by focusing on runtime discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call: 'when a runtime tool reports TARGET_AMBIGUOUS or to check what is connectable'. Also notes prerequisite 'Requires Metro running', providing clear usage context. No explicit when-not-to-use, but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| logPath | No | Path to a log file on disk (max 20MB) | |
| logText | No | Raw log text (max 256KB) — provide exactly one of logPath/logText |
| Name | Required | Description |
|---|---|---|
| errorCount | Yes | |
| diagnostics | Yes | |
| warningCount | Yes | |
| platformGuess | Yes | |
| unmatchedTail | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true). The description adds value by specifying supported log types and that output includes diagnostics, causes, and fixes, which is consistent and helpful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines purpose and supported formats, second gives usage context. Every word earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (parsing multiple build log formats into structured output), the description fully covers supported sources, output nature, and usage context. The presence of an output schema obviates the need to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, both parameters are described. The description adds the crucial detail that exactly one of logPath/logText should be provided, clarifying the mutual exclusivity beyond the schema's required field count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses native build logs (xcodebuild, Gradle, CocoaPods, Metro) into structured diagnostics with causes and fixes. It distinguishes itself from sibling tools like doctor or evaluate_js by specifying the exact input and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises using on logs from terminals, CI, or from get_build_status, providing clear context. Though it doesn't explicitly state when not to use it, the guidance is sufficient for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Minimum severity | |
| limit | No | Max entries to return (default 50) | |
| cursor | No | Read entries after this cursor (from a previous nextCursor) | |
| filter | No | Case-insensitive regex applied to entry text | |
| targetId | No | Runtime target id (from list_runtime_targets) |
| Name | Required | Description |
|---|---|---|
| dropped | Yes | Entries lost to ring-buffer overflow since the cursor |
| entries | Yes | |
| nextCursor | Yes | |
| bufferedSince | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds valuable behavioral context beyond annotations: buffering behavior and cursor-based reading. Annotations already indicate readOnlyHint=true, so no contradiction. Additional details like buffer duration could improve scoring.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second covers cursor logic and prerequisite. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core behavior, pagination, and prerequisite. Output schema exists but is not shown, so description suffices for invocation. Could mention buffer size or behavior when empty, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. The description does not add extra meaning beyond what the schema provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Read console logs from the running React Native app', with specific verb and resource. It distinguishes from siblings (none are about reading console logs) and provides context about buffering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes cursor-based pagination hint and prerequisite ('Requires Metro running'), which guides usage. However, it does not explicitly exclude alternatives or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a full JS reload of the running React Native app (same as pressing 'r' in the Metro terminal). Requires Metro running.
| Name | Required | Description | Default |
|---|---|---|---|
| targetId | No | Runtime target id (from list_runtime_targets) |
| Name | Required | Description |
|---|---|---|
| reloaded | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and openWorldHint=false. The description adds behavioral context by explaining the tool triggers a reload like pressing 'r', and notes the Metro dependency. This adds value beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the primary action, and provides a concrete analogy. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description fully covers what the tool does, its main precondition, and its effect. No additional details are needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter (targetId) is already described in the schema as 'Runtime target id (from list_runtime_targets)'. The description does not add new meaning or usage details beyond the schema, hence a baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Trigger a full JS reload'), the resource ('the running React Native app'), and an analogy ('same as pressing r in the Metro terminal'), making it specific and distinct from sibling tools like cancel_build or doctor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a precondition ('Requires Metro running'), which guides the user on when the tool can be used. However, it does not provide explicit when-not or alternative tools for similar tasks, so it's clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| clean | No | Clean before building | |
| scheme | No | iOS scheme (default: auto-detected from the workspace) | |
| variant | No | Android variant (default "debug") | |
| platform | Yes | Which native platform to build | |
| projectRoot | No | Project root (default: server --project-root) |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | |
| status | Yes | |
| command | Yes | |
| logPath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the minimal annotations (openWorldHint=false) by stating the build runs in the background and returns a job ID immediately, enabling asynchronous monitoring.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and return value (job ID); the presence of an output schema (not shown) means return details are handled, but the description could mention the output format briefly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. However, it doesn't enrich parameter understanding beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start a native build'), resource ('Gradle in the background'), and distinguishes from siblings by specifying when to use this tool versus reload_app for JS changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('after native-layer changes') and when not to ('for pure JS changes prefer reload_app'), and directs the agent to poll with get_build_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/luizhbesper/react-native-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
