Radon Mcp

Radon IDE MCP Tools

Best practices for Radon IDE's MCP tools for live React Native / Expo app inspection and debugging.

Read the relevant reference for the tool at hand. All references are in references/.

References

get_library_description

Returns a description of an npm library and its use cases from the Radon AI backend.

Input schema:

{ library_npm_name: "<npm package name>" }

Key rules

• Use the exact npm package name as published on the registry (e.g., "react-native-reanimated", "@react-navigation/native").
• This tool is for evaluation, not implementation. For API docs and usage examples, follow up with query_documentation.
• Scoped to the React Native / Expo ecosystem.

Typical workflow

1. get_library_description - understand what the library does and whether it fits. 2. query_documentation - get specific API docs and usage patterns.

Error handling

• Invalid/missing license: ensure the user has an active Radon IDE license.
• Network failure: ensure internet connectivity.

query_documentation

Returns documentation snippets from a curated React Native / Expo knowledge base on the Radon AI backend.

Input schema:

{ text: "<query string>" }

Key rules

• Write specific, focused queries targeting a concrete API or feature.
• Include the library name when relevant (e.g., "react-native-reanimated useSharedValue hook").
• Trust returned docs over training data for version-specific details - RN/Expo APIs change between versions.
• Query docs before implementing features that rely on RN/Expo APIs.
• For high-level library evaluation, use get_library_description instead.

Good vs bad queries

// Good
query_documentation({ text: "React Navigation stack navigator configuration options" })
query_documentation({ text: "expo-image-picker launchImageLibraryAsync options" })

// Too vague
query_documentation({ text: "React Native" })
query_documentation({ text: "navigation" })

Error handling

• Invalid/missing license: ensure the user has an active Radon IDE license.
• Network failure: ensure internet connectivity.

reload_application

Reloads the app in the Radon IDE emulator. Three methods with escalating scope:

Input schema:

{ reloadMethod: "reloadJs" | "restartProcess" | "rebuild" }

Reload methods

Always start with the lightest method and escalate, unless you are already certain that a more powerful restart method is required: reloadJs -> restartProcess -> rebuild.

Key behaviors

• The tool waits until the app is running before returning - safe to call view_screenshot or other tools immediately after.
• After reloading, use view_screenshot or view_application_logs to confirm the app is healthy.
• reloadJs resets all React state, context providers, and in-memory stores.

Error handling

• Reload failure: check view_application_logs for build or runtime errors.
• Device off / Radon IDE not launched: request the user to turn on the Radon IDE emulator.

view_application_logs

Returns all build, bundling, and runtime logs plus an optional PNG screenshot. Call this first when the user reports any issue.

Log sections

Missing sections mean no output on that channel - this is normal.

Key rules

• Read all sections before diagnosing - issues often span layers (e.g., native crash triggered by JS error).
• Build-time issues: focus on BUILD PROCESS + JS PACKAGER. Runtime: focus on NATIVE-SIDE + JS-SIDE.
• Based on findings, follow up with view_component_tree (layout), view_network_logs (API), or reload_application (reset).

Error handling

• No build run: select a project and device in the Radon IDE panel.
• Device off / Radon IDE not launched: request the user to turn on the Radon IDE emulator.

view_component_tree

Displays the React component tree of the running app, filtered to user-authored components with source file locations.

Output format

Indented XML-like tree with component names, source paths, line numbers, and HOC descriptors:

<MyComponent> (src/screens/HomeScreen.tsx:42)
  <Header> [memo, forwardRef] (src/components/Header.tsx:15)
    <Title> (src/components/Title.tsx:8)
      Hello World
    </Title>
  </Header>
  <Icon /> (src/components/Icon.tsx:5)
</MyComponent>

Key behaviors

• Only user-authored components are shown - node_modules components (View, Text, ScrollView, third-party) are excluded.
• Only currently mounted components are visible - conditionally rendered components with false condition won't appear.
• Paths are relative to the workspace root.

Best practices

• Pair with `view_screenshot` for layout debugging: screenshot shows the visual problem, tree reveals the structure causing it.
• Use source file paths from the tree to navigate directly to relevant code.

Error handling

• Corrupted tree: reload the app with reload_application({ reloadMethod: "reloadJs" }), then retry.
• Device off: request the user to turn on the Radon IDE emulator.

view_network_logs

Returns a paginated list of all network requests (method, URL, status, duration, size). 50 entries per page.

Input schema:

{ pageIndex: "latest" | "<number>" }

Output format

=== NETWORK LOGS (page 3/5) ===
{id: abc123} "GET https://api.example.com/users" 200 OK json 1.2kB 150ms

The requestId (e.g., abc123) is used to inspect further details with view_network_request_details.

Key rules

• Start with `"latest"` for current issues - almost always the right starting point.
• Use numeric page indexes ("0", "1", ...) to search older requests, with 0 being the oldest requests page.
• Follow up with `view_network_request_details` to inspect headers, body, and metadata of a specific request that could be problematic.
• If no logs returned, the network inspector may not be enabled - it must be active for requests to be captured.

Error handling

• Network inspector unavailable: ensure the Network panel is available in Radon IDE.
• Invalid/out-of-range page index: use "latest" or check the page header for valid range.
• Device off: request the user to turn on the Radon IDE emulator.

view_network_request_details

Returns full details of a specific network request (headers, body, metadata). Always call `view_network_logs` first to obtain the requestId.

Input schema:

{ requestId: "<string>" }

Workflow

1. view_network_logs({ pageIndex: "latest" }) - displays all recent requests. 2. You notice a request that's weird, problematic or otherwise interesting. 3. Note the requestId from the output. 4. view_network_request_details({ requestId: "<id>" }) - inspect full details of the problematic request.

Key behaviors

• Sensitive headers are redacted (case-insensitive match on: auth, cookie, token, secret, key, session, credential). You can still check header presence/absence and non-sensitive headers.
• Response bodies > 1000 chars are truncated with a placeholder showing MIME type and original size. For full payload, inspecting images and such, direct the user to the Radon IDE Network panel.

Error handling

• Request ID not found: verify it was copied correctly from view_network_logs. The request ID includes the full string within {}
• Device off: request the user to turn on the Radon IDE emulator.

view_screenshot

Captures a screenshot of the app running in the Radon IDE development viewport.

When to use

• After UI/styling changes to confirm they rendered correctly.
• After reload_application to verify the app recovered.
• When diagnosing layout or visual issues.

Key rules

• view_application_logs already includes a screenshot if the preview is ready - if logs output is already available, a separate screenshot call is redundant.
• For visual-only checks without logs, view_screenshot is the lighter option.
• The screenshot reflects current device orientation, dark/light mode, and content size settings.

Error handling

• Device off: turn on the Radon IDE emulator.