人不光是靠他生来就拥有一切，而是靠他从学习中所得到的一切来造就自己。——歌德

Mobile MCP：把移动端自动化交给统一的 MCP 接口

项目地址：https://github.com/mobile-next/mobile-mcp

移动端自动化这件事，常常卡在一个很现实的问题上：iOS、Android、模拟器、模拟器之外的真机、不同工具链、不同平台知识，彼此都像单独的一座岛。

Mobile MCP 想做的，是把这些岛连成一条可被 Agent 使用的通路。

它是一个面向移动端自动化与抓取的 MCP Server，覆盖 iOS、Android、模拟器、仿真器以及真实设备。开发者可以通过统一的接口，让 Agents 和 LLMs 与原生移动应用和设备交互，不必为每个平台单独准备一整套专门知识。

更直白地说，它试图把“怎么操控手机”这件事，变成“让 Agent 说出目标，然后由系统执行”的事。

一个统一接口，覆盖多种移动设备

Mobile MCP 的核心特征之一，是平台无关。

同一套工具可以工作在 iOS 和 Android 之上，也可以面向模拟器、仿真器以及真实设备。它不要求使用者先成为 XCUITest 或 Espresso 专家，也不需要为每个平台额外拼接复杂的胶水代码。

README 里把它概括得很清楚：

  • 适用于 iOS 和 Android 的原生应用自动化
  • 适用于模拟器、仿真器与真实设备
  • 适用于脚本化流程与表单交互
  • 适用于由 LLM 驱动的多步用户旅程
  • 适用于面向 Agent 的移动应用交互
  • 适用于移动自动化中的 Agent-to-Agent 通信与数据提取

这意味着，它不是单纯给测试人员准备的按钮集合，也不是只为截图识别准备的工具，而是一层可以被自动化、被编排、被嵌入 Agent 工作流的设备操作接口。

以可访问性树为先，必要时再回退到截图坐标

Mobile MCP 的一个很鲜明的设计方向，是优先使用可访问性树。

它主张从原生 accessibility tree 驱动应用，而不是一上来就依赖视觉模型或图像 token。只有在必要时，才退回到截图与坐标点击。

这种思路带来的直接好处，是结构化、确定性更强，成本也更低。

系统可以读取真实 UI 元素，提取结构化数据，而不是只盯着一张图片猜界面上有什么。这样做减少了纯截图方案带来的歧义，也让交互更接近设备本身的语义层，而不仅仅是像素层。

当目标是“找到这个按钮”“读取当前屏幕上的元素”“提取表单内容”时，这种结构优先的方式显得更稳。

设备管理：先知道手里有什么

移动自动化能否跑起来，第一步往往不是点击，而是确认设备状态。

Mobile MCP 提供了一组设备管理工具，用于列出可用设备、获取屏幕尺寸、读取方向、设置方向、覆盖 GPS 位置、读取或替换剪贴板等。

工具包括：

  • mobile_list_available_devices
  • mobile_get_screen_size
  • mobile_get_orientation
  • mobile_set_orientation
  • mobile_set_location
  • mobile_clipboard

这些能力看起来基础，却是移动端自动化的起点。

知道有哪些设备可用，才能决定任务要发往哪里；知道屏幕尺寸和方向，才能安排点击和手势；需要模拟位置或操作剪贴板时，也能直接调用对应工具，而不必离开统一接口。

应用管理：启动、安装、终止都在同一个工作流里

自动化不是只在界面上“点一下”那么简单。

有时候需要先安装应用，有时候需要切到指定应用，有时候则要结束一个正在运行的进程。Mobile MCP 在应用管理上提供了完整一组接口。

包括：

  • mobile_list_apps
  • mobile_get_foreground_app
  • mobile_launch_app
  • mobile_terminate_app
  • mobile_install_app
  • mobile_uninstall_app

这让 Agent 可以从“设备上有什么应用”开始，逐步进入“把哪个应用打开”“安装哪个包”“结束哪个任务”的流程。

对于测试、数据录入、流程验证、应用探索等场景，这种控制力非常实用。Agent 不只是知道界面，还能管理应用生命周期。

屏幕交互：点击、滑动、长按、录屏

真正进入移动端交互后，操作就不再只是逻辑判断，而要落到一连串具体动作上。

Mobile MCP 提供了常见的屏幕交互工具：

  • mobile_take_screenshot
  • mobile_save_screenshot
  • mobile_list_elements_on_screen
  • mobile_click_on_screen_at_coordinates
  • mobile_double_tap_on_screen
  • mobile_long_press_on_screen_at_coordinates
  • mobile_swipe_on_screen
  • mobile_start_screen_recording
  • mobile_stop_screen_recording

截图可以帮助理解当前屏幕内容，元素列表可以提供结构化 UI 信息，坐标点击则适用于可视定位，滑动和长按则能覆盖更丰富的交互方式，录屏则让整个过程可以被保存下来，便于检查和排查。

对 Agent 来说，这些工具构成了一套完整的“看见—理解—操作—验证”闭环。

输入与导航：键盘、按键、URL 都能直接触达

除了屏幕上的触摸行为，移动端还需要输入与导航能力。

Mobile MCP 支持：

  • mobile_type_keys
  • mobile_press_button
  • mobile_open_url

这意味着，Agent 可以把文本输入到聚焦元素中，可以按下 HOME、BACK、VOLUME、ENTER 等设备按键，也可以直接打开指定 URL。

它让移动端流程不必局限在“用手指模拟点点点”的层面，而是能够覆盖更完整的设备控制动作。

日志与崩溃报告：自动化不能只看成功路径

一套成熟的自动化系统，不能只在顺利时工作。

Mobile MCP 还提供日志与崩溃相关工具：

  • mobile_get_device_logs
  • mobile_list_crashes
  • mobile_get_crash
  • mobile_batch_commands

这些能力让 Agent 不只是执行操作，也能在出错时继续追踪问题。

设备日志可以帮助确认运行状态，崩溃报告可以帮助定位异常，批量命令则让一连串动作在同一次调用中完成，例如点击、输入、再点击，最后读取屏幕元素。

对于复杂流程而言，这类工具让自动化不只是“做事”，还可以“看结果”“查问题”“继续推进”。

兼容多种 MCP 客户端

Mobile MCP 并不把自己绑定在某一种客户端上。

README 明确列出，它可以与 Claude Code、Codex、Gemini、GitHub Copilot、Antigravity 等 MCP 兼容客户端一起使用，也可以接入任意支持 MCP 的客户端。

这意味着，使用者不必为了移动自动化再去更换整个 Agent 工具链，只要客户端支持 MCP，就可以接入这套设备控制能力。

安装配置也很直接。标准配置如下：

1
2
3
4
5
6
7
8
{
  "mcpServers": {
    "mobile-mcp": {
      "command": "npx",
      "args": ["-y", "@mobilenext/mobile-mcp@latest"]
    }
  }
}

从 Claude Code 到 Codex、Cursor、Gemini CLI、Windsurf、Goose、Kiro、Cline、opencode，README 都给出了对应的接入示例。它不是只对某一个生态友好，而是尽量把入口铺得足够宽。

本地设备，也可以是云端设备

Mobile MCP 不只面向你手边的设备。

它既可以运行在本机上的模拟器、仿真器和真实设备上，也可以连接到 Mobile Next Cloud，在云端使用真实的 iOS 与 Android 设备。

这为规模化场景提供了另一条路径。

如果你只是想验证一个本地流程，直接在自己的机器上跑即可；如果你要面对更大范围的设备覆盖，或者想把移动自动化纳入 CI/CD 管道，也可以借助云设备扩展。

对于 Agent 驱动的移动自动化来说，这种本地与云端并存的设计很关键。它让开发、测试、验证和规模化运行有了不同的落点。

Streamable HTTP Server：从本地进程走向可连接服务

默认情况下，Mobile MCP 通过 stdio 运行。

但它也支持以 Streamable HTTP Server 的方式启动，例如：

1
npx @mobilenext/mobile-mcp@latest --listen 3000

如果需要绑定到具体网络接口，也可以这样：

1
npx @mobilenext/mobile-mcp@latest --listen 0.0.0.0:3000

之后，客户端可以连接到对应的 /mcp 端点。

README 还说明，这种远程模式是无状态的，并提醒客户端要使用 Streamable HTTP 而不是旧的 SSE 流程。对于需要网络化部署的场景，这让 Mobile MCP 更像一个可被远程调用的服务，而不是只存在于本地终端里的工具。

认证、遥测与环境变量

当 Mobile MCP 通过 HTTP 方式运行时，还可以通过环境变量开启 Bearer Token 认证：

1
MOBILEMCP_AUTH=my-secret-token npx @mobilenext/mobile-mcp@latest --listen 3000

如果设置了该变量，请求就必须携带对应的 Authorization 头。

除了认证，README 还列出了几项环境变量：

  • MOBILEMCP_AUTH
  • MOBILEMCP_DISABLE_TELEMETRY
  • MOBILEMCP_ALLOW_UNSAFE_URLS
  • MOBILEMCP_LEGACY_ROBOT

其中，MOBILEMCP_DISABLE_TELEMETRY 可关闭匿名使用遥测。README 还说明，Mobile MCP 会通过 PostHog 和 Scarf 收集匿名使用数据，如需关闭可设置该变量。

这些配置项让运行方式更清楚，也让使用者能根据自己的环境决定是否启用认证、是否关闭遥测、是否允许非标准 URL scheme，以及是否使用旧版平台特定机器人。

适用场景非常明确

从 README 给出的用例来看，Mobile MCP 想解决的并不是一个抽象问题，而是非常具体的移动自动化场景。

例如：

  • 原生应用自动化
  • 表单录入与数据输入
  • 由 LLM 驱动的多步流程
  • 面向 Agent 的通用移动交互
  • Agent 与 Agent 之间协作完成移动任务
  • 设备上的数据提取与验证

它甚至在示例提示中给出了相当丰富的流程表达方式：搜索视频、评论、点赞、分享；下载应用、注册、设置训练计划；检索文章、标注、保存；预订课程、设置提醒；查天气并发送消息；安排会议并分享邀请。

这些示例共同说明了一件事：Mobile MCP 面向的不是单点操作，而是可持续执行的任务链。

它背后的工具栈也很清晰

Mobile MCP 是 Mobile Next 体系中的一环。

README 中提到，它与以下组件一起构成一个面向真实移动设备的工具栈：

  • mobilewright：用于把 Agent 驱动的探索转化为可重复、确定性的测试
  • mobilecli：Mobile MCP 所基于的通用设备 CLI
  • Mobile Next Cloud：按需租用的真实 iOS 与 Android 设备服务

这说明 Mobile MCP 并不是孤立存在的一个工具，而是建立在更大的移动自动化体系之上。

它负责把设备能力暴露给 MCP 客户端，而周边工具则分别承担测试、命令行控制与云端设备接入的职责。

一个面向 Agent 的移动端控制层

Mobile MCP 最打动人的地方，在于它对“移动自动化”的理解很直接。

它没有把重点放在单纯截图识别，也没有把移动端交互缩减成某种封闭脚本。它试图做的是一层通用的 MCP 控制层，让 Agent 通过统一接口理解设备、操作应用、执行流程、读取日志，并在需要时进入云端设备。

它把移动端自动化从“平台专精问题”推向“Agent 可调用的能力问题”。

对开发者而言，这意味着可以用更统一的方式去接触 iOS、Android、模拟器、仿真器和真实设备；对 Agent 而言，这意味着它能够更自然地进入移动世界，处理那些原本需要人工一条条点出来的工作流。