Provides browser automation tools specifically for React Native Web applications, enabling coordinate-based clicking, multi-tab management, screenshots, and snapshot generation.
Click on "Deploy 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., "@mcp-rnw-browser go to localhost:8081 and take a screenshot"
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.
A Model Context Protocol (MCP) browser automation server specifically designed to work with React Native Web applications. Features multi-tab support, screenshot capabilities, and persistent browser sessions.
React Native Web uses a gesture responder system that listens for mousedown/mouseup events instead of standard click events. This breaks standard browser automation tools like Playwright's locator.click() method.
Related MCP server: MCP Connect
This MCP server uses coordinate-based clicks with Playwright's low-level page.mouse API, which properly triggers the mouse events that React Native Web components listen for.
Coordinate-based clicking - Uses page.mouse.down() / page.mouse.up() instead of synthetic clicks
Multiple element finding strategies - CSS selector, text content, testID, or exact coordinates
Custom page snapshots - Shows interactive elements with positions (not reliant on accessibility tree)
Screenshot support - Returns base64-encoded PNG images that AI agents can view
Multi-tab management - Create, switch between, and close browser tabs
Persistent sessions - Browser stays open between tool calls for continuous interaction
Full browser control - Navigate, type, scroll, press keys, evaluate JavaScript
npm install @nizarius/mcp-rnw-browser
npx playwright install chromiumgit clone https://github.com/nizarius/mcp-rnw-browser.git
cd mcp-rnw-browser
npm install
npm run build
npx playwright install chromiumAdd to your Cursor MCP settings (~/.cursor/mcp.json or Cursor Settings > MCP):
{
"mcpServers": {
"rnw-browser": {
"command": "npx",
"args": ["@nizarius/mcp-rnw-browser"]
}
}
}{
"mcpServers": {
"rnw-browser": {
"command": "node",
"args": ["/path/to/mcp-rnw-browser/dist/index.js"]
}
}
}rnw_navigateNavigate to a URL. Creates a browser session if none exists.
{ "url": "http://localhost:8081" }Returns: Page snapshot with all interactive elements.
rnw_snapshotGet a text snapshot of interactive elements on the page with their positions. Returns element tags, text content, testIDs, roles, positions, and center coordinates for clicking.
// No parameters required
{}Returns: Text list of all interactive elements with their positions.
rnw_screenshotTake a screenshot and return as a base64-encoded PNG image.
// Viewport screenshot (default)
{}
// Full page screenshot (captures entire scrollable area)
{ "fullPage": true }
// Element screenshot (captures specific element)
{ "selector": "#my-component" }Returns: Base64-encoded PNG image that AI agents can view directly.
rnw_clickClick on an element using React Native Web compatible mouse events (mousedown/mouseup).
// By CSS selector
{ "selector": "button.submit", "findBy": "css" }
// By text content (partial match)
{ "selector": "Sign In", "findBy": "text" }
// By testID (data-testid attribute)
{ "selector": "login-button", "findBy": "testid" }
// By exact coordinates (useful when element detection fails)
{ "x": 500, "y": 300, "findBy": "coordinates" }Returns: Click coordinates and updated page snapshot.
rnw_typeType text into a focused element or find an element first and type into it.
// Type into currently focused element
{ "text": "Hello World" }
// Find element first, then type (clicks to focus)
{ "text": "Hello World", "selector": "input", "findBy": "css" }
// Type and press Enter (e.g., for search/submit)
{ "text": "Hello World", "selector": "input", "findBy": "css", "pressEnter": true }Returns: Confirmation of typed text.
rnw_scrollScroll the page or a specific scrollable element.
// Scroll page down by 300 pixels
{ "direction": "down", "amount": 300 }
// Scroll page up
{ "direction": "up", "amount": 500 }
// Scroll within a specific container
{ "direction": "down", "amount": 200, "selector": ".scroll-container" }Parameters: direction (up/down/left/right), amount (pixels, default: 300), selector (optional).
Returns: Updated page snapshot.
rnw_waitWait for a specified time or until an element appears on the page.
// Wait for 1 second (1000ms)
{ "time": 1000 }
// Wait for element to appear (with 5s timeout)
{ "selector": "button.loaded", "findBy": "css" }
// Wait for text to appear
{ "selector": "Loading complete", "findBy": "text" }Returns: Confirmation when wait completes or error if timeout.
rnw_press_keyPress a keyboard key. Useful for navigation, form submission, or triggering shortcuts.
// Press Enter
{ "key": "Enter" }
// Press Escape
{ "key": "Escape" }
// Press arrow keys
{ "key": "ArrowDown" }
// Press Tab to move focus
{ "key": "Tab" }Common keys: Enter, Escape, Tab, ArrowUp, ArrowDown, ArrowLeft, ArrowRight, Backspace, Delete, Space.
Returns: Confirmation of key pressed.
rnw_evaluateExecute JavaScript in the browser context. Useful for debugging, reading state, or performing custom interactions.
// Get page title
{ "script": "document.title" }
// Get current URL
{ "script": "window.location.href" }
// Read localStorage value
{ "script": "localStorage.getItem('authToken')" }
// Get element count
{ "script": "document.querySelectorAll('button').length" }
// Trigger custom action
{ "script": "window.scrollTo(0, document.body.scrollHeight)" }Returns: JSON-stringified result of the script execution.
rnw_tabs_listList all open browser tabs with their index, title, and URL.
// No parameters required
{}Returns: List of all tabs showing index, active status, title, and URL.
rnw_tabs_newCreate a new browser tab and optionally navigate to a URL. The new tab becomes the active tab.
// Create empty new tab (about:blank)
{}
// Create new tab and navigate to URL
{ "url": "http://localhost:8081/settings" }Returns: New tab index and page snapshot.
rnw_tabs_selectSwitch to a specific tab by index (0-based). Use rnw_tabs_list to see available tabs.
// Switch to second tab
{ "index": 1 }
// Switch to first tab
{ "index": 0 }Returns: Snapshot of the selected tab's page.
rnw_tabs_closeClose a browser tab. If the closed tab was active, switches to the nearest remaining tab.
// Close current active tab
{}
// Close specific tab by index
{ "index": 2 }Returns: Confirmation and snapshot of the new active tab.
rnw_session_statusGet current browser session status. Useful for checking if a session is active before performing actions.
// No parameters required
{}Returns:
isRunning: Whether browser is active
tabCount: Number of open tabs
currentTabIndex: Index of active tab
currentUrl: URL of active tab
viewport: Browser window dimensions (width x height)
rnw_closeClose the browser and end the session. All tabs are closed and resources are released.
// No parameters required
{}Returns: Confirmation that browser session has ended.
// This dispatches a synthetic 'click' event that RNW ignores
await element.click();// This triggers real mousedown/mouseup events that RNW responds to
await page.mouse.move(x, y);
await page.mouse.down();
await page.mouse.up();Agent: Let me navigate to your React Native Web app, take a screenshot, and click the login button.
> rnw_navigate { "url": "http://localhost:8081" }
Page loaded. I can see the following interactive elements:
[0] button testid="login-button"
text: "Sign In"
center: (640, 400)
> rnw_screenshot {}
[Returns PNG image of the page]
> rnw_click { "selector": "login-button", "findBy": "testid" }
Clicked at (640, 400). The login form is now visible.
> rnw_tabs_new { "url": "http://localhost:8081/settings" }
Created new tab [1] and navigated to settings page.
> rnw_tabs_list {}
Open Tabs (2):
[0] Home - http://localhost:8081/
[1] (active) Settings - http://localhost:8081/settingsThe browser session persists across tool calls, enabling:
Multi-step interactions - Navigate, screenshot, interact, screenshot again
Visual verification - Take screenshots to verify UI state after actions
Multi-page workflows - Open multiple tabs for complex testing scenarios
Debugging - Use rnw_evaluate to inspect page state
Agent: I'll test the multi-step form submission.
> rnw_navigate { "url": "http://localhost:8081/form" }
> rnw_screenshot {} // Verify initial state
> rnw_type { "text": "John Doe", "selector": "[data-testid='name-input']", "findBy": "css" }
> rnw_screenshot {} // Verify text entered
> rnw_click { "selector": "Submit", "findBy": "text" }
> rnw_screenshot {} // Verify submission result
> rnw_close {} // End session when doneMake sure your React Native Web components have testID props set
Use rnw_snapshot to see available elements
Try using text content with findBy: "text"
Ensure the element is visible and not covered by another element
Try increasing the delay with rnw_wait before clicking
Use coordinates directly if element finding fails
Ensure the browser session is active (rnw_session_status)
For element screenshots, verify the selector matches a visible element
Added screenshot support with base64 image return
Added multi-tab management (list, new, select, close)
Added session status tool
Improved tool response format
Persistent browser sessions
Initial release with RNW-compatible clicking
Basic navigation, snapshot, and interaction tools
MIT
Click on an element using React Native Web compatible mouse events. Can find element by CSS selector, text content, testID, or exact coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X coordinate (only used when findBy is 'coordinates') | |
| y | No | Y coordinate (only used when findBy is 'coordinates') | |
| findBy | No | How to find the element. Use 'coordinates' to click at exact x,y position. | |
| selector | No | CSS selector, text content, or testID to find the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It names the event mechanism but says nothing about waiting/auto-wait for the element, scrolling into view, timeout behavior, or what happens on failure — all critical for an action tool with side effects.
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 tight sentences, front-loaded with the action and mechanism, followed immediately by the targeting options. No filler or restatement of the tool name.
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 4-parameter action tool with no annotations and no output schema, the description should disclose failure modes, return behavior, and synchronization concerns. It covers targeting well but leaves the operational contract incomplete.
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 all four parameters (x, y, findBy, selector) are already documented in the schema, including the coordinates-only caveat for x/y. The description adds no syntax or usage detail beyond what the schema already provides, so the baseline of 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?
States a specific verb (click), resource (element), and execution context (React Native Web compatible mouse events), then enumerates the four targeting strategies. An agent can distinguish this from rnw_type, rnw_press_key, and rnw_scroll without opening any schema.
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 implies usage through the findBy strategies (use coordinates for exact positions), but never states when to prefer this tool over siblings like rnw_press_key or rnw_evaluate, nor any prerequisites such as the element being present or the session being active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the browser and end the session
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'End the session' hints at finality, but it does not disclose what is destroyed (tabs, cookies, in-page state), whether the session can be resumed, or what happens if called with no active session. For a terminal teardown operation this is a notable gap.
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 front-loaded sentence with zero filler; every word earns its place and the action is stated first.
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 tool is simple (zero params, no output schema), so a terse description is mostly sufficient. Still, with no annotations and no output schema, it omits the teardown side effects and error behavior an agent would want before invoking a session-ending call.
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 tool takes zero parameters, so there is no parameter semantics to convey. The baseline for a parameterless tool applies, and nothing in the description misrepresents the empty 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?
States a specific verb+resource ('Close the browser') plus the terminal effect ('end the session'), which implicitly distinguishes it from rnw_tabs_close. However, it never explicitly names that sibling, so the differentiation is left to inference.
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?
There is no guidance on when to use this versus rnw_tabs_close, nor any note about prerequisites, ordering (e.g., use after all work is done), or what to do instead if only one tab should be closed. Usage is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the browser context. Useful for advanced interactions or debugging.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden for an arbitrary-code-execution tool. It says nothing about whether the script runs in page or isolated context, whether promises/async are awaited, what value is returned, or how errors surface — all critical for an eval tool. 'Execute JavaScript' restates the mechanics without behavioral context.
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 short sentences with the core action front-loaded and zero filler. It is terse rather than padded, though the second sentence is vague enough that its value is marginal.
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 code-execution tool with no annotations and no output schema, the description should at minimum explain return-value handling, since the schema cannot. Nothing about return values, async behavior, or failure modes is covered, leaving the agent unable to predict results of a call.
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?
Only one parameter and schema coverage is 100% ('JavaScript code to execute'), so the schema fully documents the input. The description adds no syntax, format, or wrapping guidance (e.g. whether the last expression is returned, whether it must be an expression vs. a statement). 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?
States a specific verb and resource: 'Execute JavaScript in the browser context.' This is clearly distinct from the action-specific siblings (rnw_click, rnw_type, rnw_scroll), which it implicitly positions as the alternative for scripted vs. discrete actions. It stops short of explicitly naming when to prefer a dedicated sibling over raw 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?
'Useful for advanced interactions or debugging' implies the usage context but names no alternatives and gives no exclusion rule, e.g. 'prefer rnw_click/rnw_type for standard interactions.' The agent must infer that this is a fallback/escape-hatch tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a keyboard key
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key to press (e.g., 'Enter', 'Tab', 'Escape', 'ArrowDown') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and falls short. It does not say where the key is dispatched (focused element? page level?), whether modifiers like Ctrl are supported, whether the key is held or auto-released, or whether the action can trigger navigation/submission side effects.
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 short, front-loaded sentence with no waste. It is efficient, though its brevity reflects under-specification rather than disciplined trimming.
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 one-parameter, no-output-schema tool this is minimally viable, and the schema fully documents the input. But with zero annotations and no mention of focus requirements, modifier support, or side effects, an agent lacks enough context to invoke it confidently in a browser-automation flow.
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%, and the schema already gives example values ('Enter', 'Tab', 'Escape', 'ArrowDown'). The description adds nothing beyond the schema, so the 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?
States a specific verb and resource ('Press a keyboard key'), which is unambiguous on its own. However, it does nothing to distinguish itself from siblings like rnw_type (typing text) or rnw_click, so an agent must infer the boundary itself.
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?
There is no when-to-use guidance at all: nothing explains that this is for discrete key presses such as 'Enter' or 'Escape' rather than typing a string (rnw_type) or clicking an element (rnw_click). The agent is left to guess the split between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page or a specific element. Returns a base64-encoded PNG image that can be viewed by AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| fullPage | No | Whether to capture the full scrollable page (default: false, captures viewport only) | |
| selector | No | Optional CSS selector to screenshot a specific element instead of the full viewport |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the return type ('base64-encoded PNG image that can be viewed by AI agents'), which is valuable since there is no output schema, but it omits prerequisites such as whether the page must be loaded or if rnw_wait is needed, and gives no timing or size-limit context.
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 tight sentences, front-loaded with the action and followed by the return value. No filler, though the second sentence could have been spent on sibling differentiation instead of restating the obvious image format.
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 two-parameter capture tool with no output schema, the description adequately covers the action and return format. It stops short of the two things an agent most needs: how it differs from rnw_snapshot and any precondition (page readiness, waiting) before capturing.
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 both parameters are already fully documented in the schema. The description's phrase 'current page or a specific element' only echoes the schema's selector/fullPage semantics without adding format, default, or interaction detail; baseline 3 is appropriate.
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 gives a specific verb and resource: 'Take a screenshot of the current page or a specific element.' It clearly conveys the operation, but it never distinguishes itself from the sibling rnw_snapshot, which is the critical ambiguity an agent must resolve when choosing a capture tool.
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?
There is no when-to-use or when-not-to-use guidance, and no alternative is named despite rnw_snapshot and rnw_evaluate being plausible substitutes. The agent must infer from the tool name alone when a screenshot is preferable to a snapshot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll the page or a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Amount to scroll in pixels (default: 300) | |
| selector | No | Optional: CSS selector of element to scroll within | |
| direction | Yes | Direction to scroll |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It doesn't disclose whether scrolling is reversible, how it interacts with dynamic loading, or whether it triggers scroll events that might affect other state. For a mutation-adjacent action, this is a notable gap.
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 a single, efficient sentence that front-loads the action and scope. Every word earns its place, with no 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 tool's relative simplicity and full schema coverage, the description is minimally adequate. However, without annotations or output schema, it misses opportunities to clarify return values or side effects, leaving some ambiguity for an agent.
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%: each parameter (amount, selector, direction) has a clear description in the schema. The description adds nothing beyond what the schema already provides, so the baseline of 3 is appropriate.
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?
States a specific verb (Scroll) and resource (page or a specific element), clearly distinguishing it from siblings like rnw_navigate or rnw_click. An agent can immediately understand this is a viewport-scrolling operation.
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 such as rnw_evaluate or rnw_press_key. While the verb is clear, there's no mention of prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current browser session status including whether browser is running, number of tabs, current tab info, and viewport size.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses what status information is returned, and the verb 'Get' implies a read-only operation, but it does not state permissions, side effects, or freshness/format details.
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 with the verb and resource front-loaded, followed by a compact list of returned status fields. Every clause contributes and there is 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?
No output schema exists, so the description must convey return content, and it does enumerate the key status fields. For a simple zero-parameter status tool this is largely complete, though it omits return format or freshness details.
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 tool has zero parameters, so there are no parameter semantics to document. Per the scoring baseline for zero-parameter tools, a 4 is appropriate.
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 states a specific verb ('Get') and resource ('current browser session status'), then enumerates the status fields returned (running, tab count, current tab, viewport). It does not distinguish this tool from siblings like rnw_snapshot or rnw_tabs_list, so it falls short of a 5.
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?
There is no explicit when-to-use guidance, no alternatives named, and no exclusions. The phrase 'current browser session status' implies a diagnostic context, but the agent is not told when to choose this over rnw_tabs_list or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a text snapshot of interactive elements on the page. Returns element positions that can be used for clicking.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does state the return content ('element positions that can be used for clicking'), which is genuine behavioral value, but it omits the element-identifier format, whether the snapshot is stable/ref-based, and any side effects or auth context.
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 tight sentences with no waste: the core action is front-loaded and the return-value note follows immediately. Every sentence 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?
With no annotations, no output schema, and no parameters, this is a simple tool and the description covers both what it does and what it returns. The remaining gap is the format of the returned element identifiers, which matters for wiring into rnw_click.
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 tool takes zero parameters, so there is no parameter meaning to convey and the baseline is 4. The description does not confuse matters by describing nonexistent inputs.
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 names a specific verb ('Get') and resource ('text snapshot of interactive elements on the page'), and 'text' implicitly distinguishes it from the sibling rnw_screenshot. It is clear without being an explicit sibling differentiation, so a 4 fits.
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 line 'positions that can be used for clicking' implies this is a precursor to rnw_click, which is useful implied guidance. However, it never says when to choose this over rnw_screenshot or rnw_evaluate, and there are no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a browser tab by index. If no index provided, closes the current tab.
| Name | Required | Description | Default |
|---|---|---|---|
| index | No | Optional index of the tab to close. Defaults to current tab. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. Closing a tab is a mutation, and the description says nothing about whether it is reversible, what happens to the closed tab's state, whether an invalid index errors or is ignored, or how the active tab changes afterward.
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 short sentences, front-loading the action and immediately following with the default-case behavior. Every sentence earns its place with 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?
For a one-optional-parameter tool with no output schema, the essentials are covered: what it does, and what happens when no index is given. What is missing is disambiguation from rnw_close and any note on error behavior for an invalid index.
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% and the schema already documents 'index' as the optional tab index defaulting to the current tab. The description restates this without adding format, indexing base, or out-of-range behavior, so 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?
States a specific verb (close) and resource (browser tab) with the default behavior made explicit, so the agent can tell it apart from rnw_close and rnw_tabs_list by name. However it does not explicitly distinguish itself from the similarly named rnw_close sibling, leaving the tab-vs-session scope to inference.
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 hints at usage by describing the no-index default, but gives no when-to-use guidance, no prerequisites, and no contrast with siblings like rnw_close or rnw_tabs_select. The agent must infer the boundary between closing a tab and closing a session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open browser tabs with their index and URL
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavioral trait that the tool operates on open browser tabs, but says nothing about permissions, whether it involves server round-trips, error modes when no tabs are open, or any side effects. Minimal but not misleading.
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?
Single front-loaded sentence with no waste. It's appropriately sized for a zero-parameter read tool, though it offers no additional context.
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 zero-parameter tool with no output schema or annotations, the description leaves return-format details implicit (e.g., what index means, output array structure). Adequate but with clear gaps in behavioral and output context.
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?
Zero parameters, so baseline is 4. The description appropriately states no filtering or scoping options, consistent with an empty input 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?
Specific verb (List) and resource (open browser tabs) with scope ('all'). Clearly distinguishes from tab-management siblings like rnw_tabs_new, rnw_tabs_select, rnw_tabs_close by describing a read operation over existing tabs.
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?
Implies usage (enumeration of open tabs) but provides no explicit when-to-use context or routing to alternatives like rnw_tabs_select for acting on a tab. An agent can infer the purpose but isn't guided on when this versus other tab tools is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new browser tab and optionally navigate to a URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional URL to navigate to in the new tab |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and discloses very little beyond the core action. It does not say whether the new tab becomes the active/focused tab, how it affects existing tabs, whether creation is idempotent, or what the call returns (e.g. a tab id), all of which matter for a state-mutating session tool.
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?
One short sentence with the core action front-loaded and no filler. Nothing could be trimmed without losing meaning.
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 one-parameter tool this covers the essentials, but with no annotations and no output schema it leaves gaps an agent would care about: tab focus behavior, return value, and how it relates to rnw_navigate/rnw_tabs_select.
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% and the schema already documents the single url parameter as 'Optional URL to navigate to in the new tab'. The description merely restates this, adding no format, validation, or default-value detail beyond the schema, so the 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?
States a specific verb (create) and resource (new browser tab) plus the optional follow-on action (navigate to URL). It clearly contrasts with rnw_tabs_list/select/close by virtue of creating rather than managing, but it never explicitly differentiates itself from rnw_navigate, so it stops short of a 5.
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 word 'optionally' hints that navigation can be done separately (i.e. create a blank tab and use rnw_navigate), but no when-to-use or when-not-to-use guidance is given. No prerequisites or alternatives are named, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a specific browser tab by index (0-based)
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | The index of the tab to switch to (0-based) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden but discloses almost nothing: it does not say what happens with an out-of-range index, whether the switch is synchronous, or what errors are returned. For a browser-control mutation of active focus, this is a meaningful gap.
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?
One short, front-loaded sentence with zero filler; the index semantics are not buried. It is appropriately sized for a single-parameter tool, though it is terse to the point of omitting useful context.
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 one-parameter tool with no output schema the description covers the core action, but it leaves the agent without failure-mode or sequencing guidance (e.g., obtaining valid indices), which is the minimum extra context this tool needs.
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% and the single parameter's schema already documents the 0-based indexing. The description merely repeats that fact, adding no syntax, range, or sourcing information beyond the schema, so the 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?
States a specific verb ('Switch to') and resource ('browser tab') with the indexing scheme, which cleanly separates it from rnw_tabs_list, rnw_tabs_new, and rnw_tabs_close. It does not explicitly name those siblings, but the distinct action verb makes selection unambiguous.
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 only says what the tool does; it gives no when-to-use context, no prerequisites (e.g., that the tab index must come from rnw_tabs_list), and no alternatives. An agent must infer the usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into a focused element or find an element and type into it
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type | |
| findBy | No | How to find the element | |
| selector | No | Optional: CSS selector to find the element first | |
| pressEnter | No | Press Enter after typing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether typing appends to or replaces existing content, that it fires input/keydown events, what happens when no element is found, or whether focus is required — all important for a browser mutating action.
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 efficient sentence with the primary action front-loaded. Nothing is wasted, though it is arguably under-specified rather than truly concise.
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 mutation-style browser tool with no annotations and no output schema, the description covers the basic mechanics but omits error/failure behavior, content replacement semantics, and relationship to adjacent keyboard tools, leaving gaps an agent may need.
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 the schema already documents all four parameters (text, findBy, selector, pressEnter). The description adds no syntax or format detail beyond that, so 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?
States a specific verb (type) and resource (text) and names the element target, which is clear. It is distinguishable from rnw_press_key by virtue of being text entry, though it never names that sibling explicitly.
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 two modes (type into focused element, or find an element first) imply usage, but there is no explicit when-to-use/when-not guidance and no mention of alternatives such as rnw_press_key or rnw_click for selecting the field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a specified time or for an element to appear
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | Time to wait in milliseconds | |
| findBy | No | How to find the element | |
| selector | No | CSS selector to wait for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether the wait blocks the session, what happens on timeout (error vs silent return), or whether 'time' and 'findBy'/'selector' are mutually exclusive or combined.
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 efficient sentence with the two modes front-loaded and zero filler. It is appropriately sized for a simple tool, though it could carry a little more without becoming bloated.
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 3-param tool with no annotations and no output schema, the description covers the basic purpose but leaves the mode interaction and timeout/failure behavior unspecified. Adequate as a minimum, but not complete.
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 the schema already documents all three parameters and the enum for findBy. The description only restates the two modes at a high level, adding no syntax or precedence details beyond the schema, so the 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?
States a specific action (wait) with two clear modes: a duration or an element-appearance condition. No sibling tool competes with it in the set, so no differentiation is needed, but it doesn't describe its role in the broader flow.
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?
No guidance on when to use this versus simply issuing the next action, nor which mode (fixed time vs element wait) is preferable or how they interact. The agent must infer everything about applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.1rnw_clickrnw_closernw_evaluaternw_navigaternw_press_keyrnw_screenshotrnw_scrollrnw_session_statusrnw_snapshotrnw_tabs_closernw_tabs_listrnw_tabs_newrnw_tabs_selectrnw_typernw_waitScored across 15 tools
Each tool maps to a distinct browser action or session/tab operation. Snapshot vs screenshot and evaluate vs click/type are clearly differentiated by their descriptions. No two tools appear to do the same thing.
All tools share the rnw_ prefix and snake_case, which makes them readable and groupable. However, the internal pattern is not uniformly verb_noun (e.g., rnw_tabs_list, rnw_session_status vs rnw_navigate, rnw_click), so there are minor deviations.
15 tools for a browser automation server is well within the useful range. Each tool covers a necessary primitive: navigation, inspection, interaction, tab management, and session lifecycle. No obvious redundancy.
Core browser automation lifecycle is covered, including navigation, interaction, tab management, and session teardown. Advanced interactions like hover, drag, file upload, iframe handling, or network interception are absent, but agents can work around many via rnw_evaluate.
Automate cloud Chrome—navigate, click, type, screenshot, run code, record screen video
Programmatic headless browser sessions: create, interact, browse, and extract - rendered in a real
remote debug iOS/Android/Unity/Godot/Flutter/RN/Web on real-device.ui-tree/screenshots/taps,tests.
Undetectable cloud browser sessions for AI agents and scrapers. Navigate, extract, click, captcha.