iOS Screenshot MCP Server
This server enables automated interaction with iOS devices and simulators via Appium, allowing AI clients to visually inspect and control iOS apps.
📸 Take Screenshots: Capture the current screen of an iOS device or simulator and save it as an image file, with configurable device, app, and Appium server settings.
👆 Click UI Elements: Tap on specific UI elements identified by their accessibility ID, enabling automated navigation and interaction within apps.
🌳 Dump UI Element Tree: Retrieve the full UI element hierarchy of the current screen in XML format, useful for inspecting app structure and identifying elements for automation.
Key details:
Connects to a locally running Appium server (
http://127.0.0.1:4723by default)Supports both Stdio and SSE modes for MCP-compatible clients
Shares a single Appium session across all tools to avoid redundant connections
Compatible with real iOS devices and simulators via the XCUITest framework
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., "@iOS Screenshot MCP ServerTake a screenshot of the iPhone 16 Pro Max home screen"
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.
iOS Appium MCP Server
基于 Appium 的 iOS 设备自动化测试 MCP Server,支持屏幕截图、元素点击和 UI 树获取,可用于 Trae 等支持 MCP 协议的 AI 客户端。
安装依赖
uv syncRelated MCP server: SilbercueSwift
运行方式
方式一:Stdio 模式(推荐用于 Trae)
uv run python mcp_server.py --stdio方式二:SSE 模式(用于远程连接)
uv run python mcp_server.py服务器将在 http://localhost:8000 运行。
Trae MCP 配置
Stdio 模式(推荐)
将以下 JSON 配置添加到 Trae 的 MCP Servers 配置中:
{
"name": "iOS Screenshot MCP",
"type": "stdio",
"command": "uv run python mcp_server.py --stdio",
"cwd": "~/mcp-servers/ios-playwright-mcp",
"enabled": true
}SSE 模式
先启动服务器:
cd ~/mcp-servers/ios-playwright-mcp
uv run python mcp_server.py将以下 JSON 配置添加到 Trae 的 MCP Servers 配置中:
{
"name": "iOS Screenshot MCP",
"type": "sse",
"url": "http://localhost:8000/mcp/sse",
"enabled": true
}Claude code MCP 配置
"mcpServers": {
"ios-playwright": {
"name": "ios-playwright",
"type": "stdio",
"command": "bash",
"args": [
"-c",
"source ~/mcp-servers/ios-playwright-mcp/.venv/bin/activate && uv run python ~/mcp-servers/ios-playwright-mcp/mcp_server.py --stdio"
],
"cwd": "~/mcp-servers/ios-playwright-mcp/"
}
}工具说明
take_ios_screenshot_tool
截取 iOS 设备屏幕并保存为图片文件。
参数:
参数 | 类型 | 默认值 | 说明 |
platform_name | str | iOS | 平台名称 |
automation_name | str | XCUITest | 自动化框架名称 |
device_name | str | iPhone 16 Pro Max | 设备名称 |
udid | str | 32EFED52-E30A-4CC8-AAE9-525B5A3A5B6A | 设备唯一标识符 |
bundle_id | str | com.xue.Demo01 | 应用 Bundle ID |
appium_server_url | str | Appium 服务器地址 | |
output_path | str | screen.png | 截图保存路径 |
返回值:
截图文件的完整路径。
element_click_tool
通过 accessibility_id 点击 iOS 设备上的元素。
参数:
参数 | 类型 | 默认值 | 说明 |
accessibility_id | str | - | 元素的 accessibility identifier(必填) |
platform_name | str | iOS | 平台名称 |
automation_name | str | XCUITest | 自动化框架名称 |
device_name | str | iPhone 16 Pro Max | 设备名称 |
udid | str | 32EFED52-E30A-4CC8-AAE9-525B5A3A5B6A | 设备唯一标识符 |
bundle_id | str | com.xue.Demo01 | 应用 Bundle ID |
appium_server_url | str | Appium 服务器地址 |
返回值:
操作结果消息。
dump_ui_element_tool
获取 iOS 设备当前屏幕的完整 UI 元素树(XML 格式)。
参数:
参数 | 类型 | 默认值 | 说明 |
platform_name | str | iOS | 平台名称 |
automation_name | str | XCUITest | 自动化框架名称 |
device_name | str | iPhone 16 Pro Max | 设备名称 |
udid | str | 32EFED52-E30A-4CC8-AAE9-525B5A3A5B6A | 设备唯一标识符 |
bundle_id | str | com.xue.Demo01 | 应用 Bundle ID |
appium_server_url | str | Appium 服务器地址 |
返回值:
UI 元素树的 XML 字符串。
前置条件
调用截图工具前需要确保:
Appium Server 已启动在
http://127.0.0.1:4723目标设备/模拟器已连接
指定的应用(
bundle_id)已安装在设备上
文件结构
.
├── mcp_server.py # MCP Server 主文件
├── screenshot_service.py # Appium 服务模块(会话管理、截图、点击、UI树)
├── main.py # 原始截图脚本
├── pyproject.toml # 项目配置
└── README.md # 项目说明会话管理
所有工具共享同一个 Appium 会话,避免重复建立连接。会话在首次调用任一工具时创建,保持活跃状态直到服务器停止。
Available Tools
1 tooltake_ios_screenshot_toolC
截取 iOS 设备屏幕并保存为图片文件
Args:
platform_name: 平台名称,默认为 iOS
automation_name: 自动化框架名称,默认为 XCUITest
device_name: 设备名称,默认为 iPhone 16 Pro Max
udid: 设备唯一标识符
bundle_id: 应用 Bundle ID
appium_server_url: Appium 服务器地址
output_path: 截图保存路径
Returns:
截图文件的完整路径
| Name | Required | Description | Default |
|---|---|---|---|
| udid | No | 32EFED52-E30A-4CC8-AAE9-525B5A3A5B6A | |
| bundle_id | No | com.xue.Demo01 | |
| device_name | No | iPhone 16 Pro Max | |
| output_path | No | screen.png | |
| platform_name | No | iOS | |
| automation_name | No | XCUITest | |
| appium_server_url | No | http://127.0.0.1:4723 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only states the action (screenshot) and output path, but fails to mention side effects, error conditions, or whether it is read-only. The agent gains no insight into safe usage.
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 concise with a brief statement, followed by a structured Args and Returns section. However, the Args list largely duplicates schema information, slightly reducing efficiency.
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 7 parameters and no annotations, the description is insufficient. It does not explain how to set output_path, supported formats, or behavior when defaults are overridden. The output schema existence is acknowledged but not detailed, leaving gaps for the 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 description coverage is 0%, and the description merely lists parameter names and defaults (e.g., 'udid: 设备唯一标识符') without adding meaning beyond the parameter names. The agent cannot infer proper values or constraints.
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 explicitly states the tool takes an iOS device screenshot and saves it as an image file, using specific verbs and resource. With no sibling tools to differentiate, it fully clarifies what the tool does.
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, prerequisites (e.g., device connection, Appium setup), or situations to avoid. The description simply states the action without context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
take_ios_screenshot_tool
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools. The tool's purpose is clearly defined.
The single tool name follows a consistent snake_case pattern, which is fine. There is no inconsistency within the set.
One tool is too few for a server dedicated to iOS screenshots. Even though the tool is parameterized, a minimal set would include at least a device listing or connectivity check tool.
The core functionality of taking a screenshot is covered, but missing tools for device discovery, status checks, or screenshot management leave notable gaps in the surface.
Maintenance
Related MCP Connectors
MCP server for Appcircle mobile CI/CD platform.
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- AlicenseBqualityFmaintenanceA server that captures screenshots from iOS Simulator using the Model Context Protocol (MCP) and saves them to a specified directory.115 npm8MIT

SilbercueSwiftofficial
AlicenseNot gradedqualityBmaintenanceHigh-performance MCP server for iOS development and test automation. Gives AI coding assistants direct access to iOS simulators with sub-20ms screenshots, UI interaction, building, testing, and an intelligent operator mode.8MIT- AlicenseNot gradedqualityCmaintenanceMCP server for iOS automation via rpcclient, enabling AI agents to connect to iOS RPC servers and perform actions like launching apps, clicking, typing, and gesture control.2MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for cross-platform mobile automation (iOS/Android) using accessibility trees and screenshots, enabling agents to interact with apps on simulators, emulators, and physical devices.7Apache 2.0