最近后台不少人在问mobile-mcp这个词有的把它当成某个开源项目有的在问“手机怎么获取 MCP 服务”还有人拿着某 MCP 网关的提示截图来问我“这个提示说只支持移动设备访问是怎么回事”我把这段时间在移动端折腾 MCP 的经验整理成一篇东西mobile-mcp 到底指什么、移动端跑 MCP 有哪几条路线、怎么从零把一个 MCP 服务接到手机里以及最容易卡住人的几个坑。内容尽量照顾到完全没接触过 MCP 协议的新手也会给出一些可以直接抄作业的配置和代码。1. mobile-mcp 到底是什么先分清移动端的两种玩法1.1 MCP 协议是干嘛的为什么和手机有关系MCP 全称 Model Context Protocol中文一般叫模型上下文协议。它解决的是一件很朴素的事让 AI 应用能安全地调用外部工具和数据源。你可以把 MCP 理解为 AI 世界的 USB-C 接口——以前每个 AI 应用接外部工具都要写一套私有集成有了这个协议模型、客户端、工具服务端就能按统一的方式对话。协议本身基于 JSON-RPC 2.0消息通常是initialize、tools/list、tools/call这一类。工具服务端把能力暴露出来AI 客户端发现这些工具后在需要的时候调用。这个过程很像我们去店里点菜菜单是工具清单下单是调用工具上菜是返回结果。为什么 mobile-mcp 会被单独拿出来说因为手机是我们最高频的终端但绝大多数 MCP 示例都是跑在电脑上的。电脑上可以轻松跑 Python 服务、开浏览器调试工具、连本地数据库手机就没那么方便。于是就有了两类典型需求一类是把手机上的能力传感器、文件、短信、剪贴板暴露给电脑上的 AI 用另一类是让手机上的 AI 助手去调用远程的 MCP 服务。1.2 手机当客户端还是当服务端我把移动端 MCP 的玩法拆成两条路线这样后面遇到具体场景时不容易绕晕。第一条路线是手机作为 MCP 客户端。手机上装一个支持 MCP 的 App或者自己写一个最小客户端然后让它去连接远程的 MCP Server。典型场景是手机上的 AI 助手连接企业内部的 MCP 网关查订单、查库存、发消息。这时候手机只是个“遥控器”真正的计算和工具执行都发生在服务端。第二条路线是手机作为 MCP 服务端。手机通过 HTTP/WebSocket 把自身能力暴露出来电脑上的 AI 客户端比如 Claude Desktop、Cursor通过局域网或公网访问。常见做法是手机监听一个本地端口电脑用adb forward或局域网 IP 连接。这种模式适合做自动化测试、传感器采集或者把手机当成一个独立的“工具节点”。现在很多项目里说的mobile-mcp其实是指第二种——让手机变成一个可以随时被 AI 调用的移动工具集。但我在实际接触中发现大部分提问者需要的是第一种他们手里已经有一个 MCP 服务地址比如wss://api.xiaozhi.me/mcp/?token...只是想搞清楚手机怎么连上去。所以我在下文会两条路线都覆盖但会以“手机连远程 MCP 服务”为主线。2. 手机怎么获取 MCP 服务从协议到端口的完整链路2.1 获取 MCP 服务端的三种渠道先解决源头问题MCP 服务从哪来第一种是用现成的公共服务平台。现在有不少团队把自己平台的 API 封装成 MCP 端点用户申请 token 后直接在客户端里填地址就能用。比如小智 MCP 平台提供的api.xiaozhi.me/mcp端点就属于这一类。这类服务最大的好处是省事不用自己搭建坏处是权限和数据都攥在别人手里适合尝鲜和轻量使用。第二种是自建 MCP Server。用 Python 或 Node 写一个服务把自己常用的 API、脚本、数据库查包装成 MCP 工具。这种方式适合有定制需求的场景比如把内部运维脚本暴露给 AI。热词里提到的swagger 转 mcp也是这个思路——把已有的 HTTP API 描述文件转换成 MCP Server快速让 AI 能调用现有的后端接口。第三种是改造桌面软件自带的 MCP 能力。现在很多专业工具已经内置了 MCP Server比如 Chrome DevTools MCP、Playwright MCP、Figma MCP、蓝湖 MCP、甚至 Unity MCP、Blender MCP。它们本来跑在电脑上但只要你把服务绑定到局域网或公网地址手机端同样能连。2.2 移动端连接 MCP 的网络链路选择拿到服务端之后手机要连上去有三条常见链路同一局域网直连手机和 MCP Server 连同一个 WiFi手机直接访问ws://192.168.x.x:端口。优点是延迟低缺点是不能出门。通过公网服务器中转把 MCP Server 部署在云服务器上手机随时随地通过公网访问。这是最实用的方式。通过网关/WSS 接入服务端使用wss://协议配合 token 鉴权。手机端只需要支持 WebSocket 客户端即可。从实际体验看MCP 走 WebSocket 比走普通 HTTP 更适合移动端原因有两个一是 WebSocket 是长连接AI 对话过程中会多次调用工具长连接能省去反复握手的时间二是wss://走 TLS 加密token 不容易在传输中被截获。很多公共服务平台选择wss://api.xxx.com/mcp/?tokenxxx这种格式就是这个道理。这里要特别提醒一句token 就是钥匙。我看到网上有人分享截图时没有打码直接把?.token.....整串丢出来。如果你手里的 token 是生产环境的泄露后等于把服务控制权交出去了。轻则被别人刷爆额度重则你的数据被拉走。截图时一定要把 token 中间段打码。2.3 手机端“获取 MCP 服务”的通用四步以“让手机连接一个远程 MCP 服务”为例完整的流程可以浓缩成四步申请/配置 token确认服务端的地址形如wss://api.example.com/mcp/?token你的token。确认传输协议。大多数公共服务用 WebSocket少数用 SSE 或 Streamable HTTP。在手机客户端里填入地址。如果客户端不支持 MCP 协议则需要写一个最小 WebSocket 客户端来做 JSON-RPC 消息转发。发起initialize握手再拉tools/list工具列表然后试调一个工具验证连通性。这一步看起来简单但第 3 步往往是坑最多的地方。很多手机 App 虽然打着“AI 助手”的旗号却没有暴露自定义 MCP 地址的入口。遇到这种情况我建议先用电脑端验证服务可用再用支持 MCP 的手机客户端最后才考虑自己写转发层。3. 一次真实的 mobile-mcp 接入实战手机连接 wss MCP 服务3.1 准备工作先在电脑上验证服务可用我不建议一上来就在手机上折腾因为手机端的问题和协议问题会混在一起很难排查。正确顺序是先在电脑上把服务调通再去解决手机适配。假设你要连的是wss://api.xiaozhi.me/mcp/?tokenxxxx第一步是在支持 MCP 的客户端里配置。如果你用 Chrome DevTools 的 MCP 扩展可以在浏览器扩展设置中直接启用“MCP 连接”并填入地址。如果你用 Claude Desktop 或 Cursor也可以在配置文件的mcpServers里加上{ mcpServers: { xiaozhi-mobile: { url: wss://api.xiaozhi.me/mcp/?token你的token } } }注意不同客户端的配置字段略有差异有的用url有的用commandargs来启动本地 MCP Server。连 WebSocket 远程服务时关键就是url字段不要写错包括wss://前缀和 token 参数。验证成功的标志是什么打开客户端里的 MCP 工具列表能看到服务端暴露出来的工具调用一个无副作用的工具能正常返回结果。到这一步说明服务端是好的token 是好的协议交互是通的。3.2 用 Python 快速写一个手机能连的 MCP Server如果你的需求是“手机当服务端”或者你想自己起一个 MCP 服务给手机用我推荐用 FastMCP 这个库。它封装了协议细节你可以把精力放在写工具函数上。先安装依赖pip install fastmcp uvicorn然后写一个最小服务暴露一个返回手机信息的模拟接口from fastmcp import FastMCP mcp FastMCP(mobile-demo-server) mcp.tool() def get_device_info() - dict: 返回一个模拟的设备信息示例实际项目中可以在这里读取手机传感器或状态 return { device: android-emulator, battery: 85, network: wifi, } if __name__ __main__: mcp.run(transportstreamable-http, host0.0.0.0, port8000)host0.0.0.0很关键它表示监听所有网卡这样手机才能通过电脑的局域网 IP 访问。跑起来后手机在同一个 WiFi 下就能通过http://电脑IP:8000/mcp访问服务。如果你想用 WebSocket 协议需要换一种启动方式。FastMCP 底层支持不同的 transport但目前最常见的远程部署组合是streamable-httpuvicorn。如果你对接的平台只认wss://通常是在前面加一层 HTTPS/WSS 网关或者直接用支持 WebSocket 的 MCP Server 框架。3.3 在手机上写一个最小 MCP 客户端手机上没有现成客户端时可以用 Flutter、React Native 或原生 WebSocket 写一个简单的测试程序。核心逻辑很简单就是发 JSON-RPC 消息。我用 Dart 语言举例import dart:convert; import dart:io; Futurevoid main() async { final ws await WebSocket.connect(wss://api.example.com/mcp/?token你的token); // 1. 发送 initialize 请求 ws.add(jsonEncode({ jsonrpc: 2.0, id: 1, method: initialize, params: { protocolVersion: 2025-06-18, capabilities: {}, clientInfo: {name: mobile-client, version: 1.0.0} } })); ws.listen((data) { final msg jsonDecode(data); if (msg[id] 1) { // 2. 初始化完成后请求工具列表 ws.add(jsonEncode({ jsonrpc: 2.0, id: 2, method: tools/list, params: {} })); } if (msg[id] 2) { // 3. 打印工具列表 print(jsonEncode(msg)); } }); }这段代码没有处理生命周期管理但足够验证“手机能否连上服务”。在实际项目中你还需要处理以下内容notifications/initialized通知、心跳保活、断线重连、tool 调用结果的解析。调试的时候打开服务端日志看握手记录是最直接的。下面专门聊日志。3.4 MCP Server 端日志的自定义管理热词里有一条问“MCP server 端的日志如何使用自定义日志管理”这确实是远程部署时容易忽略的点。默认情况下很多 MCP 框架会把日志打到标准输出但服务以 systemd 或容器方式运行时标准输出会被吞掉出了问题时什么都看不到。我给自己的 MCP Server 配日志时一般按下面这套来import logging from logging.handlers import TimedRotatingFileHandler logger logging.getLogger(mcp-server) logger.setLevel(logging.DEBUG) handler TimedRotatingFileHandler( logs/mcp-server.log, whenmidnight, backupCount7, encodingutf-8 ) formatter logging.Formatter(%(asctime)s - %(levelname)s - %(name)s - %(message)s) handler.setFormatter(formatter) logger.addHandler(handler)关键点有三个一是按天轮转防止日志文件无限膨胀二是固定编码为 UTF-8因为工具返回的文本经常带中文三是把DEBUG级别打开MCP 的 JSON-RPC 消息很长只有 DEBUG 级别才能看到完整报文。等排查完再调回 INFO避免日志刷得太猛。如果你的服务部署在容器里我建议把日志输出到 stdout/stderr由容器的日志驱动统一收集而不是直接写到容器内文件。原因很简单容器重启后文件就没了统一收集才能集中检索。4. 把 PC 上的 MCP 能力“搬”到手机常见场景拆解4.1 浏览器调试Chrome DevTools MCP 和 Playwright MCP移动端页面调试一直是痛点而 Chrome DevTools MCP 的出现让 AI 可以直接操作浏览器。这个场景和手机的关系是你可以让 AI 通过 Chrome DevTools MCP 打开手机模拟器尺寸的视口操作页面、抓取接口、检查控制台报错。很多人在网上问“Browser Use MCP 跟 Playwright MCP 有什么区别”我简单说下。Browser Use MCP 偏“让 AI 替你完成网页操作”它封装的是整个浏览器自动化流程Playwright MCP 偏“把浏览器当工具暴露给 MCP 调用”更底层适合做精准控制。如果你只是想快速让 AI 帮你测一个移动端页面用 Playwright MCP 配合设备模拟器就够了。实际操作中我会在电脑上起一个 Playwright MCP Server绑定到局域网地址然后在手机端用一个支持 MCP 的客户端去触发浏览器操作。效果就像手机遥控电脑上的浏览器一样适合演示和远程协助。4.2 安全测试工具链BurpSuite MCP、Yakit MCP 与 CTF安全工具接入 MCP 也是今年的热门方向。比如 BurpSuite MCP 和 Yakit MCP 可以把抓包工具的能力暴露给 AIAI 能直接读取 HTTP 请求、修改重放、分析接口逻辑。在授权测试和 CTF 比赛中这种能力能省不少事。这些工具默认跑在电脑上手机要连同样走远程 MCP 网关。要注意的是安全测试工具链的信息非常敏感暴露到公网之前必须做鉴权和访问控制。我见过有人把 BurpSuite MCP 直接绑到公网端口上没有任何 token这是一个非常危险的操作——别人拿到了你的 MCP 工具列表等于拿到了你的抓包工具手柄。这种服务至少要做到token 鉴权、IP 白名单、TLS 加密、审计日志。热词里提到的“Trae IDE 搭载 Burp Suite MCP Server 完整指南”也是同一个思路只是把客户端换成了 Trae IDE。这类方案适合有授权的渗透测试人员在隔离环境里使用不建议在公网环境长期开放。4.3 设计协作与软件自动化Figma MCP、蓝湖 MCP设计协作场景同样有 MCP 需求。Figma MCP 可以把设计稿的图层、样式、标注暴露给 AI蓝湖也提供了 MCP 服务。有人问“蓝湖 MCP 服务怎么部署”这类商业服务通常不需要你自己部署而是由平台方提供一个 MCP 端点你在客户端里配置账号和项目 ID 就行。这类 MCP 服务的优势是AI 可以直接读取设计稿尺寸生成代码时能对应到真实的样式 token。我在 VSCode 里配合 Figma MCP 试过几次效果比截图给 AI 描述要准确得多尤其间距和颜色这种细节AI 不会猜错。手机在这个场景里起什么作用主要是“随时看”。设计师在手机上看效果图发现细节不匹配时可以直接把问题和 MCP 工具反馈给电脑上的 AI不用再手动截图、圈红、写文字说明。工具链打通之后反馈链路短很多。4.4 专业软件里的 MCPUnity、Blender、QGIS 等热词里还有 Unity MCP、Blender MCP、Vivado 的 MCP、NXOpen MCP 之类的关键词。这说明 MCP 已经不局限于 AI 聊天工具接 API而是逐渐进入专业软件控制领域。比如 Unity MCP 可以让 AI 读场景结构、修改 GameObject、执行 Editor 脚本Blender MCP 可以让 AI 操作三维模型、改材质、跑渲染。这对移动端的意义在于你可以带着手机远程连接一台高性能工作站的 MCP 服务让 AI 在后台执行重活手机只用来下发指令和查看结果。我在实际使用中发现一个规律凡是有 Python 脚本接口或命令行接口的软件包成 MCP 都不难。难点往往在鉴权和权限控制。因为 MCP 工具的能力等同于执行代码一旦暴露到公网风险比 API 泄露大得多。专业软件授权一般也有限制开放远程 MCP 前务必先确认授权条款是否允许。5. 常见问题与排查技巧实录5.1 手机连不上 MCP 服务先从这五步查我把平时帮人排查的顺序整理成一个表你可以照着做。现象排查点解决方向连接超时网络不通、防火墙拦截、域名解析失败手机和服务端确认在同一网络或可互访检查云服务器安全组端口握手失败协议版本不匹配、token 无效、TLS 证书问题抓取握手报文检查protocolVersion字段更换有效 token能连上但工具列表为空服务端没正确加载工具、鉴权拒绝访问看服务端日志确认工具注册是否成功检查 token 权限调用工具报错JSON-RPC 参数格式错误、工具内部异常在客户端打印原始请求/响应报文对照 JSON-RPC 2.0 规范手机访问提示“only supports mobile device access”服务端按客户端类型做了限制按提示改用手机浏览器或手机端 App 访问不要在 PC 端强行绕过最后一行要说明一下我之前也看到过某个 MCP 网关提示“此网站只支持移动设备访问请使用你的手机上的 MCP 客户端”。这种提示一般出现在网页助手或移动端专属服务上意图很明确——该服务就是给手机用户用的。最省事的做法就是直接拿手机访问别在电脑上费劲。5.2 调用工具返回“超时”或“连接被断开”MCP 调用一个耗时的工具时客户端很容易因为等待时间太长而主动断开。比如 AI 要调用一个批量处理图片的工具执行时间超过 30 秒WebSocket 连接可能就被中间层断开了。处理办法有两个方向。一是把耗时操作改成异步任务模式工具只负责提交任务并返回 task_idAI 另查一个工具去轮询任务状态。二是调大客户端和服务端的读写超时参数。FastMCP 里可以通过mcp.run(transportstreamable-http, timeout_keep_alive...)这类参数调整具体名称取决于框架版本。我强烈建议优先用异步任务模式而不是单纯调大超时。因为移动端网络本身就不稳定长连接超过 60 秒几乎必断靠超时参数解决不了本质问题。5.3 在手机上自建 MCP Server 的“省电”与“保活”在手机上跑服务端的读者一定会遇到两个现实问题耗电和进程被杀。耗电主要来自 WebSocket 长连接。如果你的手机服务端只是给电脑提供工具调用可以考虑在无请求时进入休眠由客户端侧自动重连而不是一直保持活跃。我之前在一个 Android 项目里就是让服务监听 TCP 连接15 秒没有消息就断开客户端侧写好自动重连逻辑功耗能降一半以上。进程被杀则几乎无解。国产手机厂商的后台管理策略非常激进一个前台 App 的 Service 都可能在锁屏后被回收。我的经验是开发调试阶段用电脑模拟器替代真机生产阶段把真正需要常驻的逻辑放到云端服务器手机端只做轻量的采集和转发这样既稳定又省电。5.4 日志排查看不到有效信息怎么办很多人问为什么日志里全是INFO和WARNING看不到 JSON-RPC 报文。因为大多数框架默认日志级别就是 INFO不会把请求内容打出来。你需要显式开启调试级别或者自己加一个中间件来打印收发的消息。如果你用的是 FastMCP可以通过配置logging级别来开启export MCP_LOG_LEVELDEBUG python server.py如果是自建服务直接在自己封装的 WebSocket 处理函数里print出收到的原始帧。虽然不优雅但排障时最管用。等你确认问题出在哪个环节再把这些打印删掉也不迟。6. 一些实操之后才明白的事mobile-mcp 这个概念说到底并没有多么高深它只是把 MCP 协议的适用范围从桌面端扩展到了移动端。但真正做下来我发现大家踩的坑都和“移动”两个字有关网络不稳定、后台被杀、token 管理不便、日志难以查看。大原则一句话手机适合做轻量客户端和临时服务端不适合做长周期的高强度计算节点。我在实际项目中最后采取的结构一般是云端起一个 MCP Server手机上跑一个轻量客户端两者之间走wss://长连接token 定期轮换服务端日志统一收集到日志平台。这样一来无论是电脑还是手机都能以相同的接口访问工具链不用为每个终端单独适配。最后再分享一个小技巧测试 MCP 服务时不要一上来就用真实 token 去连生产环境。先在本地起一个最简单的 FastMCP 服务然后用电脑、手机轮流通一遍把协议和网络链路都摸清再切换到正式服务。这个习惯能帮你避开大量“客户端配置错误”和“网络不通”的低级问题。我自己就是因为跳过这一步浪费过整整一个下午。