把游戏引擎编辑器接入 AI 客户端，关键不在"工具多"，而在"工具面是否可控、执行入口是否够灵活"。我们在 Funplay MCP for Unity 上验证过这套取向之后，把同样的思路带到了 Cocos Creator——这就是 Funplay MCP for Cocos。

它是一个 MIT 协议的 Cocos Creator 扩展，在编辑器内部直接跑一个 HTTP MCP server。AI 助手（Claude Code、Cursor、Codex、VS Code Copilot、Trae、Kiro）通过标准 MCP 协议连进来，就能检视并操作你正在开发的 Cocos 项目——而不需要单独的 Python 守护进程或外部桥接。

一个嵌入式 MCP server，而不是外挂进程

很多引擎自动化方案的做法是"引擎侧开个 socket，外面再起一个翻译进程"。Funplay MCP for Cocos 不走这条路：MCP server 本身就嵌在 Cocos Creator 扩展里。

安装方式就是普通的 Cocos 扩展——把仓库放进项目的 extensions/ 目录：

cd /path/to/your-cocos-project
mkdir -p extensions
git clone https://github.com/FunplayAI/funplay-cocos-mcp.git extensions/funplay-cocos-mcp

重启 Cocos Creator 后，从编辑器菜单打开 Funplay > MCP Server 面板即可启动服务。默认监听 http://127.0.0.1:8765/，端口被占用时自动回退到下一个可用端口，并用真实运行端口去做一键客户端配置。

这是一个纯编辑器扩展——它的目标是自动化 Cocos Creator，不会给你最终发布的游戏包引入任何运行时依赖。

execute_javascript：scene 与 editor 双上下文

整个工具集围绕一个主力工具构建：execute_javascript。AI 客户端提交一段 JavaScript，扩展在 Cocos 内部执行——区别只在于跑在哪个上下文：

• context: "scene" —— 在当前 Cocos 场景 / 运行时上下文里执行，用来构建节点树、挂组件、读运行状态
• context: "editor" —— 在 Cocos 编辑器 / 浏览器上下文里执行，用来做编辑器侧自动化

举一个具体的例子。当你对 AI 说：

“在当前场景里做一个登录页 UI：账号、密码输入框，一个登录按钮，一个游客登录按钮。”

AI 客户端的执行路径是：用 execute_javascript（scene 上下文）在当前 Canvas 下搭好节点层级、挂上 Cocos 组件，再 inspect 一遍结果，最后截一张图做视觉校验。整个过程不需要为"创建输入框""创建按钮"分别定义专用工具。

这就是设计上的关键取舍：与其堆几十个细粒度工具让 LLM 在 tools/list 里挑花眼，不如给它一个能力完整的执行入口，再用少量聚焦工具补足截图、诊断、资源检视等场景。

core / full / custom 三档工具暴露

execute_javascript 是主线，但不是全部。Funplay MCP for Cocos 一共注册了 89 个工具，覆盖场景层级、编辑器状态、选择工作流、预制体、资源、UI 创建、组件、文件、日志、脚本诊断、截图、运行时控制、输入模拟。

直接把 89 个工具全部暴露给 AI 客户端并不是好主意——工具越多，LLM 的选错率、选漏率、token 开销都越高。所以工具暴露分三档：

档位	暴露范围	适用场景
core	34 个高频工具	默认值，工具面收敛，适合大多数会话
full	全部 89 个工具	需要完整自动化面时切换
custom	按分类 / 单个工具增删	精细调优暴露面

core 集合是刻意做小的：execute_javascript 系列、编辑器状态、场景与层级、预制体检视、资源操作、脚本诊断、日志、性能快照、运行时状态、各类截图——34 个工具，刚好在"一个 LLM 上下文窗口能完整审视"的量级。需要更大自动化面时再在面板里切到 full。

资源、Prompt 与结构化返回

除了工具，这个包还暴露了另外三层 MCP 能力：

• Resources —— cocos://project/context（完整项目与编辑器上下文）、cocos://project/summary、cocos://scene/active 等，让 AI 不必靠工具调用就能读到项目全貌
• Prompts —— fix_script_errors、create_playable_prototype、scene_validation、auto_wire_scene 等可复用工作流
• Interaction history —— 最近的工具调用记录，在面板的 Recent Activity 里可见

工具返回也不是裸字符串。结构化结果统一走一个信封：ok、tool、callId、summary、data，以及指向后续操作的 refs。工具清单里还带上 MCP 的 outputSchema 与 annotations——这些都是为了让 AI 客户端能基于机器可读字段做分支判断，而不是去 parse 自然语言。

文件类工具和 cocos://asset/path/... 资源被限制在当前 Cocos 项目根目录内，不会越界访问。

接入 AI 客户端：面板里一键配置

连接 AI 客户端不需要手写配置。Funplay > MCP Server 面板里有 MCP Client Config 区块：选目标客户端、点 One-Click Configure，扩展会把推荐的 MCP 配置项写进去。写入客户端的 server 名是 funplay_cocos。

支持一键配置的客户端：Claude Code / Claude Desktop、Cursor、VS Code、Trae、Kiro、Codex。手动配置的话，HTTP 形式很简单：

{
  "mcpServers": {
    "funplay_cocos": {
      "type": "http",
      "url": "http://127.0.0.1:8765/"
    }
  }
}

如果你的客户端只接受本地 stdio 命令，仓库还提供了 npm 包装器：

npm install -g funplay-cocos-mcp

它把 stdio MCP 流量桥接到 Cocos 内嵌的 HTTP 端点。也可以直接 npx funplay-cocos-mcp --url http://127.0.0.1:8765/。

连上之后，建议先发几个安全请求验证链路：调 get_project_info 总结当前项目、读 cocos://project/context、用 execute_javascript（scene 上下文）返回当前场景名。这些都通了，说明 server、resources、prompts、主执行工具都接好了。

与 Funplay MCP for Unity 的关系

Funplay MCP for Cocos 与 Funplay MCP for Unity 是同一套设计原则在不同引擎上的落地，差异主要来自引擎本身的编辑器环境：

维度	Funplay MCP for Cocos	Funplay MCP for Unity
编辑器集成	Cocos Creator 扩展	Unity Editor 包
嵌入式 server	内置 HTTP MCP server	内置 HTTP MCP server
主执行工具	execute_javascript	execute_code
主语言	scene / editor 上下文里的 JavaScript	Unity 编辑器 / 运行时里的 C#
默认档位	core（34 工具）	core（聚焦工具集）
完整档位	89 工具 + custom	79 工具
客户端接入	一键配置面板	一键配置窗口

如果你同时在做 Unity 和 Cocos 项目，两套 MCP server 的心智模型几乎一致：默认看到收敛的 core 工具集，主线是一个高灵活度执行工具，需要时切 full，截图和输入模拟做视觉校验。

写在最后

把引擎编辑器接入 AI，真正的难点不是"能不能调到 API"，而是"工具面是否对 LLM 友好"。Funplay MCP for Cocos 把这一点作为第一设计目标：工具默认收敛、执行入口够灵活、返回结构化、资源与 Prompt 补足上下文。

项目开源在 FunplayAI/funplay-cocos-mcp，MIT 协议，支持 Cocos Creator 3.8+。如果它对你的 Cocos 工作流有帮助，欢迎在 GitHub 上点个 Star。