📌 项目地址：mobile-next/mobile-mcp | ⭐ 10,273 颗星（更新于 2026-11-04） | 🔧 TypeScript
移动端自动化一直有个麻烦：iOS 要写 XCUITest，Android 要写 Espresso，两套技术栈、两套环境。模拟器和真机的接入方式也不一样。mobile-mcp 把这些收拢到一个 MCP Server 里，你在 Claude Code、Codex、Gemini、GitHub Copilot 或任何 MCP 兼容客户端里描述目标，Agent 就直接去操作手机上的原生应用。
7223 个 star，TypeScript 写的，项目有简体中文 README。
核心设计：不靠截图，靠无障碍树
市面上不少“AI 操作手机”的方案走截图路线：每一步截屏、传图、让视觉模型猜该点哪。慢，贵，而且不确定。
mobile-mcp 反着来：从原生无障碍树驱动应用，直接读真实的 UI 元素，拿到的是结构化文本，不消耗图像 token。只有必要的时候才回退到截图加坐标点击。
这个选择带来两个直接后果。第一是便宜，无障碍快照是纯文本，跑一个几十步的流程，成本比传几十张图低得多。第二是确定，Agent 读到的是真实元素属性，“按钮存不存在、文案是什么”不用靠猜。对需要稳定判断的自动化来说，这点很关键。
支持的设备和前置条件
| 目标 | 前置条件 |
|---|---|
| iOS 模拟器 | Xcode + 已启动的模拟器（xcrun simctl） |
| iOS 真机 | USB 连接并已信任 |
| Android 模拟器 | Android SDK + 运行中的模拟器（adb） |
| Android 真机 | adb + 已授权的 USB 调试 |
同一套工具 API 覆盖这四种目标，不用写平台特定的胶水代码。你不需要懂 XCUITest 或 Espresso，描述目标就行，Agent 自己决定怎么操作。
能做什么
设备层面能做的事很全：点击、滑动、手势，应用安装/启动/终止，录屏，硬件按键，深链，屏幕旋转。
README 里明确列出的 MCP 工具有两个：
mobile_list_available_devices：列出所有可用设备（模拟器、仿真器、真机）mobile_get_screen_size：获取设备屏幕像素尺寸
原子操作本身不难，有意思的组合用法是拿 LLM 驱动多步骤用户旅程。比如让 Agent 在真机上跑完一整个注册或下单流程，自己处理每一步的表单和弹窗。官方也提到了 agent-to-agent 场景：多个 Agent 协作做移动端自动化和数据抽取。
泼点冷水
它不是装完就能用。本地跑 iOS 依然要装 Xcode，Android 依然要 SDK 和 adb。省掉的是写两套平台脚本的工作，不是开发环境本身。
项目方同时推 Mobile Next Cloud，一个付费的云端真机服务，用同一套工具操作云端的 iOS/Android 设备，免本地配置。这是它的商业模式，开源仓库本身不受影响。
还有一点要想清楚：Agent 驱动的自动化天然不如脚本稳定。如果你的场景是每天跑几千次的回归测试，传统方案可能仍然更合适。mobile-mcp 的优势在需求多变、写脚本不划算的地方：探索性测试、数据录入、从 App 里抽取结构化数据。
我的判断
如果你已经在用 Claude Code 这类工具，又需要覆盖移动端，mobile-mcp 值得直接试。我觉得最有说服力的用法是：让 Agent 在真机上走一遍新用户的完整流程，然后告诉你卡在哪一步、界面上实际显示的是什么。这种事以前要么自己手动点一遍，要么花几天写测试脚本。
觉得维护两套 Appium 脚本太重的团队，也可以拿它评估替代。