MCP server for Radon IDE integration with React Native debugging
Radon-MCP demonstrates good effort in tool naming and descriptions, with clear, context-rich guidance for each tool. All 11 tools have explicit definitions with input schemas. However, there are notable gaps in schema completeness, parameter descriptions, and output documentation that prevent a higher score. Naming is strong (verb-noun pattern consistently applied). Descriptions are detailed and contextual (averaging ~250-400 chars), which is above baseline. The critical weakness is that most tools lack complete input schemas, many parameters are missing or descriptions are trivial. Output schemas are almost entirely undocumented. Error handling is basic and does not guide recovery. Security considerations (command injection via path traversal) are present but incomplete.
Check Radon IDE and Metro bundler status. Returns diagnostic information: - Radon device: connected/disconnected/error - Metro bundler: running/unreachable/error - System: healthy/degraded/unavailable WHEN TO USE: - Before starting debug session - When tools return errors - To verify environment setup RELATED TOOLS: - view_screenshot: Requires Radon device - view_application_logs: Requires Metro bundler
Reset iOS Simulator status bar to default values. Use after set_status_bar to restore normal status bar. RELATED TOOLS: - set_status_bar: Customize status bar values - view_screenshot: Verify reset
Get information about the current iOS Simulator device. Returns: - Device name and model - iOS version (runtime) - Device UDID - Current state WHEN TO USE: - Understand testing context - Debug device-specific issues - Verify simulator configuration RELATED TOOLS: - check_system_health: Full system diagnostics - view_screenshot: Verify simulator is running
Get npm package information including metadata, dependencies, and README. USE CASES: - Check library compatibility before adding to project - Find peer dependencies for React Native libraries - Read installation instructions from README RESPONSE INCLUDES: - Version, license, homepage, repository URL - Dependencies and peer dependencies (important for RN!) - README content (truncated by readmeLimit) RELATED TOOLS: - query_documentation: Search official RN/Expo docs - view_application_logs: Check for errors after installing EXAMPLES: - Full info: {library_npm_name: "react-native-reanimated"} - Quick lookup: {library_npm_name: "expo-camera", readmeLimit: 1000}
Multiple tools with 'additionalProperties: false' but no properties defined: view_screenshot, check_system_health, clear_status_bar, get_device_info. These tools accept no parameters, yet the schema is minimal and provides no documentation of what they return or do.
No output/response schemas documented for any tool. LLMs cannot plan downstream tool calls or extract the right data without knowing what fields to expect. Critical for composition and chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Open a URL or deeplink in the iOS Simulator. WHEN TO USE: - Navigate to specific screen via deeplink - Test URL handling in app - Open external URLs EXAMPLES: - Deeplink: myapp://profile/123 - Web URL: https://example.com - Settings: app-settings: WORKFLOW: 1. open_url with deeplink 2. view_screenshot → verify navigation 3. view_application_logs → check for errors RELATED TOOLS: - view_screenshot: Verify navigation after opening URL - view_application_logs: Check for deeplink handling errors
Generate links to React Native or Expo documentation. Returns URLs to official documentation pages. Use WebFetch to retrieve content. RELATED TOOLS: - get_library_description: Get npm package info and README - view_application_logs: Debug after following docs
Switch iOS Simulator between dark and light mode. WHEN TO USE: - Test dark mode styling after UI changes - Verify colors, contrast, icons in both themes - Debug theme-specific issues WORKFLOW: 1. set_appearance → dark 2. view_screenshot → verify dark mode UI 3. set_appearance → light 4. view_screenshot → compare RELATED TOOLS: - view_screenshot: Verify theme changes visually
Grant or revoke app permissions in iOS Simulator. WHEN TO USE: - Test permission flows (camera, location, photos) - Debug permission-denied scenarios - Automate permission setup for testing ACTIONS: - grant: Give permission - revoke: Remove permission - reset: Reset to default SERVICES: camera, photos, location, microphone, contacts, calendar, reminders, etc. EXAMPLE: Grant camera access to com.myapp.bundle RELATED TOOLS: - view_screenshot: Verify permission dialog or UI change
Override iOS Simulator status bar for consistent screenshots. WHEN TO USE: - Standardize screenshots (time, battery, signal) - App Store screenshots preparation - Consistent visual testing OPTIONS: - time: Status bar time (e.g., "9:41") - batteryLevel: 0-100 - cellularBars: 0-4 - wifiBars: 0-3 Use clear_status_bar to reset to default. RELATED TOOLS: - clear_status_bar: Reset to default values - view_screenshot: Capture standardized screenshot
Get application logs from React Native app. Reads Metro JS console logs via CDP WebSocket. PARAMETERS: - filter: Regex to grep specific lines FIRST (errors, warnings, component names) - last: Then take last N lines from filtered result ORDER: Raw logs → filter (if set) → last (if set) → truncate to 200 lines OUTPUT INCLUDES: - Summary header: [Showing X of Y lines, matched Z] - Log content with [SKIPPED N LINES] marker if truncated WHEN TO USE: - After view_screenshot to debug visible issues - Find JS errors: filter:"error|Error|exception" - Recent activity: last:50 - Specific component: filter:"MyComponent" RELATED TOOLS: - view_screenshot: See current UI state first, then check logs EXAMPLES: - All logs: {} → first 50 + last 150 lines - Last 50: {last: 50} - Errors: {filter: "error|Error"} - Recent errors: {filter: "error", last: 100}
Capture current screen of iOS Simulator. Returns compressed JPEG image (max 800px, ~50-100KB) of device screen. WHEN TO USE: - START HERE for debugging - see current UI state - Verify UI changes after code modifications - Debug layout issues (positions, sizes, alignment) - Confirm navigation state (which screen is active) - See error screens, alerts, modals WORKFLOW: 1. view_screenshot → see current state 2. view_application_logs → check JS console for errors 3. Fix code 4. Repeat RELATED TOOLS: - view_application_logs: Check JS console after seeing UI issue NOTE: Requires Radon IDE with active iOS Simulator.
view_application_logs parameters 'filter' and 'last' lack proper descriptions. 'filter' is described as regex but not clearly stated it is case-insensitive until deep in examples. 'last' lacks min/max bounds. No guidance on what happens if both are omitted.
set_status_bar has optional parameters with no defaults specified. Unclear what happens if 'time' is omitted but 'batteryLevel' is set, are all fields independent? Undocumented interdependencies invite misuse.
get_library_description 'readmeLimit' parameter is optional with default 5000, but no guidance on what 'too large' looks like or when the LLM should use smaller values. Description hints at '1000-2000 for quick lookups' but this is advisory, not enforced.
Error handling in device-bridge.js uses execSync with timeouts but error messages are generic ('error.message'). No guidance on retryability, user-fixable vs. fatal errors, or next steps for the agent.
set_privacy 'bundleId' parameter is a string with no validation constraint documented. LLMs may guess invalid formats. Should document expected format (e.g., 'com.company.appname', 3+ segments separated by dots).
Tools that call execSync (view_screenshot, open_url, set_appearance, etc.) via device-bridge.js do not validate inputs against command injection risk. deviceId and deviceSet are validated via validateDeviceId/validatePath, but the validation code is not shown. Potential path traversal risk if validators are insufficient.