把 Cocos Creator 编辑器接入 AI：Funplay MCP for Cocos 介绍

把游戏引擎编辑器接入 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 扩展里。
HTTP JSON-RPC
AI 客户端

Claude Code / Cursor / Codex
Cocos Creator 扩展
嵌入式 MCP Server
execute_javascript
scene 上下文

场景 / 运行时
editor 上下文

编辑器 / 浏览器

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

bash 复制代码

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。
89 个注册工具
core: 34 个
full: 89 个
custom: 自定义增删
默认暴露给 AI 客户端
需要时手动切换

资源、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 形式很简单：

json 复制代码

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

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

bash 复制代码

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。