Allows taking screenshots of Android emulators and analyzing them with AI for UX improvements.
Compatible with Flutter apps running on emulators/simulators for screenshot capture and AI analysis.
Allows taking screenshots of iOS simulators and analyzing them for UI/UX feedback.
Compatible with React Native apps running on emulators/simulators for screenshot capture and AI analysis.
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., "@Mobile Xray MCP Take a screenshot of my iOS simulator and suggest UI improvements"
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.
🔬 Take screenshots and analyze your mobile apps with AI assistance - right from your IDE.
Privacy First • Built by Developers for Developers • Works Locally
I've been building mobile apps for the last 10 years, and one thing that's been consistently challenging without a dedicated UX designer is knowing whether the screens I create are actually user-friendly and intuitive.
Now, this has become dramatically easier. With Mobile Xray MCP, you can ask your favorite AI-powered IDE (Claude, Cursor, Windsurf, VS Code) to take a screenshot of your app and give you instant suggestions on what to improve. No more guessing about UI/UX decisions - get feedback directly in your development workflow.
This tool bridges the gap between development and design by bringing mobile app analysis capabilities directly into your coding environment, making it easier than ever to create polished, user-friendly mobile applications.
Related MCP server: Enhanced ADB MCP Server
🔒 Privacy First: All automation happens locally on your machine - your app screenshots and data never leave your device
⚡ Fast: Direct communication with local simulators and emulators for instant feedback
📱 Cross-Platform: Supports both iOS simulators and Android emulators
🤖 AI-Powered: Integrates seamlessly with AI coding assistants for intelligent analysis
👨💻 Developer-Focused: Built by developers who understand the mobile development workflow
Prerequisites: Node.js 18+, iOS Simulator or Android Emulator
Add to your IDE config file:
{
"mcpServers": {
"mobile-xray": {
"command": "npx",
"args": ["-y", "@cultivx/mobile-xray-mcp"]
}
}
}Test: Restart IDE → Start simulator → Ask: "Take a screenshot of my iOS simulator"
System Requirements:
Node.js 18+ (check with node --version)
macOS 10.15+ (for iOS development)
macOS/Windows/Linux (for Android development)
For iOS Development:
Xcode Command Line Tools: xcode-select --install
Xcode with iOS Simulator support
At least one iOS Simulator installed
For Android Development:
Android Studio (includes adb and emulator commands)
Android SDK tools in your PATH
At least one Android Virtual Device (AVD) created
Verify Your Setup:
# Test Node.js version
node --version # Should show v18.0.0 or higher
# Test iOS tools (macOS only)
xcrun simctl list devices | head -5
# Test Android tools
adb versionFor Cursor: See Cursor MCP Documentation
For Claude Desktop: See Claude MCP Quickstart
For Windsurf: See Windsurf MCP Documentation
For VS Code: See VS Code MCP Documentation
Note: This MCP server works with any AI coding assistant that supports the Model Context Protocol.
Start your mobile simulator/emulator
Open your AI chat in your IDE
Ask for a screenshot: "Can you take a screenshot of my iOS simulator?"
Get AI analysis: "What can I improve about this screen's UX?"
Check which platforms are currently supported by the mobile-xray-mcp on my machineTake a screenshot of my iOS simulator and tell me what accessibility features I should addScreenshot my current screen and check if the color contrast meets accessibility standardsTake a screenshot of the current iOS simulator, and find the code that is related to it, then propose some improvements without making any changesTake a screenshot of my app and suggest improvements for mobile-first design principlesAnalyze the current screen layout and suggest improvements for better user flowMake changes and verify your changes work well by taking a screenshotIssues:
"No simulators found": Start your simulator with open -a Simulator (iOS) or check adb devices (Android)
MCP not connecting: Restart your IDE after adding config, verify JSON syntax is correct
"Command not found": Install Xcode Command Line Tools (xcode-select --install) or ensure Android SDK is in PATH
Common Questions:
Frameworks: Works with React Native, Flutter, Xamarin, or any app in simulator/emulator
Physical devices: Not yet supported, simulators/emulators only
Privacy: The MCP server operates locally and doesn't collect or send any data. Screenshot images are sent to your AI service by your IDE for analysis
Offline: Screenshots work offline, AI analysis needs internet connection
✅ Platform Detection: Automatically checks which mobile platforms are available on your system
✅ Privacy First: All processing performed by the MCP server happens locally - no data sent to external servers. However, screenshot images will be sent to your AI service (Claude, ChatGPT, etc.) for analysis, as handled by your IDE's AI agent
✅ Screenshot Capture: Take instant screenshots of iOS simulators and Android emulators
✅ Cross-Platform Support: Works with both iOS and Android development environments
✅ IDE Integration: Seamlessly works with popular AI-powered IDEs and coding assistants
🚧 Interactive Navigation: Enable AI assistants to navigate through your app interface
We welcome contributions! Here's how you can help:
Fork this repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
I'll review all PRs and provide feedback. Whether it's bug fixes, new features, or documentation improvements - all contributions are appreciated!
This project is licensed under the Apache License 2.0 - see the LICENSE file for details.
🐛 Issues: GitHub Issues
📖 Documentation: Model Context Protocol Docs
Made with ❤️ by developers, for developers
Check which platforms are supported
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates this is a safe read operation, and the description aligns with that. However, it adds no extra behavioral context such as output format, latency, or any side effects, so it meets the baseline without exceeding it.
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, short sentence that communicates the purpose without any unnecessary words or repetition. It is front-loaded and efficient.
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 (no parameters, no output schema), but the description does not specify what the result will look like or what 'platforms' refers to in context. Given the simplicity, this is minimally adequate but could we benefit from mentioning the return type or examples.
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, and the schema already covers everything (100% coverage). With no parameters, there is no need for parameter explanation, so the baseline of 4 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?
The description uses the verb 'Check' with the resource 'platforms', clearly indicating a read/query operation. It is distinct from sibling tools like get_simulator_screenshot and get_simulator_list, which focus on simulators, though the term 'platforms' is somewhat broad.
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 is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all simulators
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | The state of the simulator | |
| platform | Yes | The platform of the simulator |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint: true, which covers the safety profile. The description adds no further behavioral context—no mention of filtering semantics, return format, or any side effects. The word 'all' could be seen as contradictory to the required filters, but this is more a clarity issue than a transparency issue.
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, concise sentence with no wasted words. However, the use of 'all' is imprecise given the required filters, which slightly reduces structural quality. Still, it is well under the typical length and 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?
For a simple list tool, the description is incomplete. It does not mention that platform and state are required filters, what the output list contains, or whether there are any limitations or pagination. The schema does provide parameter details, but the description leaves out essential contextual information about the return value and invocation prerequisites.
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 fully describes both parameters (platform and state) with enums, so schema coverage is 100%. The description 'Get a list of all simulators' adds no parameter-specific meaning 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?
The description clearly states the tool's action ('Get a list') and resource ('simulators'), distinguishing it from siblings like get_simulator_screenshot and check_supported_platforms. However, the phrase 'all simulators' is slightly misleading because the required parameters indicate the list is filtered by platform and state.
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 merely states what it does, leaving the agent to infer usage context. There is no mention of exclusions or alternative tools, despite the presence of 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 screenshot of the iOS simulator
| Name | Required | Description | Default |
|---|---|---|---|
| deviceId | Yes | The UDID for the iOS simulator, and the emulator ID for the Android simulator | |
| platform | Yes | The platform of the simulator |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide readOnlyHint=true, so the agent knows it's a safe read operation. The description adds no additional context such as output format, platform nuances, or side effects. Moreover, the reference to 'iOS simulator' conflicts with the schema's support for Android, misrepresenting the tool's behavior.
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, short sentence, making it easy to read. However, it includes the inaccurate 'iOS' qualifier, which reduces precision despite its brevity.
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 tool with two parameters and no output schema, the description is too minimal. It doesn't mention that the platform parameter can be 'android', nor does it describe what the screenshot output looks like (e.g., file path, base64). The readOnly annotation covers safety but not functional completeness.
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 100% coverage with descriptive comments for both deviceId and platform, including an enum. The tool description adds no extra parameter meaning, 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?
The description uses a specific verb 'Get' and resource 'screenshot', and it clearly differs from sibling tools like get_simulator_list. However, it inaccurately limits the tool to 'iOS simulator' when the schema explicitly supports both iOS and Android, making the purpose slightly misleading.
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 tool or how it relates to alternatives like get_simulator_list or check_supported_platforms. The description only states what it does, leaving the agent to infer when it should be invoked.
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.
v0.0.6check_supported_platformsget_simulator_listget_simulator_screenshotScored across 3 tools
Each tool targets a distinct concern: capturing screenshots, listing simulators, and checking platform support. There is no overlap or ambiguity between them.
Most tools follow a get_ pattern, but check_supported_platforms uses check_ instead. This is a minor deviation from an otherwise clear verb_noun convention.
Three tools is a reasonable count for a focused utility server. It is not overly sparse, though it could benefit from one or two more related tools to feel more substantial.
The tool set covers basic simulator operations and platform discovery, but lacks common related operations such as booting a simulator or retrieving device details. It feels incomplete for broader mobile testing workflows.
Capture screenshots, detect visual regressions between page versions, and analyze with AI.
Run App Store Connect from your IDE: pricing, listings, screenshots, releases, AI visibility.
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
Approved test intent, reviewed Playwright automation and run evidence, inside your editor.
