UnrealMCP - AI控制Unreal Engine的MCP项目汇总

更新时间：2026-03-04

MCP (Model Context Protocol) 是让 AI 助手直接控制 Unreal Engine 的桥梁。以下是目前活跃维护的优秀 UnrealMCP 项目。

BTW：

• Cluade CLI配置文件路径： C:\Users\Eugene\.claude.json 这一个文件里面会保存不同路径的MCP方案

• Rider Copilot的Mcp配置文件的位置：C:\Users\Eugene\AppData\Local\github-copilot\intellij\mcp.json

• VSCode的Claude Code MCP配置：

  %APPDATA%\Code\User\settings.json (通过VScode设置（Ctrl+,）搜索MCP开启设置)

  VSCode的项目级别的配置，需要在项目目录里面留有一个.vscode/mcp.json文件。

  文件结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

{
  "mcpServers": {
    "blueprintMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "blueprint_mcp_server.py"]
    },
    "editorMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "editor_mcp_server.py"]
    },
    "umgMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "umg_mcp_server.py"]
    },
    "nodeMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "node_mcp_server.py"]
    },
    "datatableMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "datatable_mcp_server.py"]
    },
    "projectMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "project_mcp_server.py"]
    },
    "blueprintActionMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "blueprint_action_mcp_server.py"]
    },
    "materialMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "material_mcp_server.py"]
    },
    "niagaraMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "niagara_mcp_server.py"]
    },
    "soundMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "sound_mcp_server.py"]
    },
    "statetreeMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "statetree_mcp_server.py"]
    },
    "animationMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "animation_mcp_server.py"]
    },
    "fontMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "font_mcp_server.py"]
    },
    "pcgMCP": {
      "command": "uv",
      "args": ["--directory", "d:\\SVN\\UnrealMCP\\Python", "run", "pcg_mcp_server.py"]
    }
  }
}

🔥 主流项目对比

⭐ 项目

1. flopperam/unreal-engine-mcp (半商业) （已测试🆗）

• 项目地址: https://github.com/flopperam/unreal-engine-mcp
• 官网: https://flopperam.com/
• Stars: 532 ⭐
• 语言: Python
• UE版本: 5.5, 5.6, 5.7
• 维护状态: ✅ 活跃维护（最后更新：2026-02-14）

核心优势：

• 🎨 完整 Blueprint 编辑（v0.7 新功能）
• 🏗️ 世界构建（城镇、城堡、豪宅、迷宫）
• 🤖 Flop Agent（内置 Agent，嵌入 UE 编辑器）
• 🎮 3D 生成（文本/图片 → 3D）

⚠️ 注意：半开源项目

• MCP Server: ✅ 完全开源
• UE Plugin: ✅ 免费
• Flop Agent: 基础功能免费，高级功能需付费
• 3D 生成: Good 质量免费， High/Very High 需付费
• AI 模型: Sonnet/GPT 5.2 免费， Opus 4.6 需付费

定价：

适合: 需要完整 Blueprint 编辑、3D 生成、内置 Agent 的团队

2. chongdashu/TrishynVolodymyr/unreal-mcp (最老牌)（已测试🆗）

• 项目地址: https://github.com/chongdashu/unreal-mcp
• Stars: 1,498 ⭐ (Fork 225)
• 语言: Python
• 维护状态: ✅ 活跃维护

特点:

• 社区最大，资源最丰富
• 支持 Cursor、Windsurf、Claude Desktop
• 基础的 Actor 操作、材质、关卡编辑

局限:

• 主要用于蓝图分析，不能直接编辑蓝图
• 没有 3D 生成能力

适合: 快速上手、需要社区支持的团队

- *说明*: 目前使用的是TrishynVolodymyr / unreal-mcp版本的MCP。chongdashu/unreal-mcp版本的这个作者长期没有更新了。这个版本的MCP是Unreal5.7的，跑通了测试了一下，能实现很多基础功能，功能很全，基于python脚本来实现很多功能。如果是5.7的项目，再优化一下配置流程就基本上是可用级别的了。但是我尝试将这个项目改成5.6的项目失败了，有大量的接口工作需要去修改。

3. prajwalshettydev/UnrealGenAISupport (多模型支持)

• 项目地址: https://github.com/prajwalshettydev/UnrealGenAISupport
• Stars: 415 ⭐
• 语言: C++ (UE Plugin)

特点:

• 支持 多种 LLM: OpenAI GPT、DeepSeek、Claude、Gemini、本地模型
• 内置 MCP Server
• 支持多模态 API（图片生成等）
• 支持 Perforce / Git 版本控制

适合: 需要在 UE 内直接调用各种 LLM API 的团队

4. ChiR24/Unreal_mcp (TypeScript + C++)（覆盖最全）（已测试🆗）

• 项目地址: https://github.com/ChiR24/Unreal_mcp
• Stars: 328 ⭐
• 语言: TypeScript + C++
• UE版本: 5.0-5.7

特点:

• 使用 UE 原生 C++ Automation Bridge 插件
• 支持 NPM 包安装 (npx unreal-engine-mcp-server)
• 动态类型发现
• GraphQL API 支持
• Docker 支持
• 44+ 工具

适合: 需要企业级功能和 TypeScript 生态的团队

备注：需要在Unreal路径底下启动服务器，比如我的： $env:UE_PROJECT_PATH=”D:\SVN\Solution_5_6”; npx unreal-engine-mcp-server（这个启动方式有点过分地优雅了）。但是它的UE插件实现方法过于有问题，大量的McpAutomationBridge_XXXXX代码，每一个文件都极其的长，非常不适合AI来维护。

5. GenOrca/unreal-mcp

• 项目地址: https://github.com/GenOrca/unreal-mcp
• 语言: Python
• UE版本: 5.6+
• 特点: 完整的 Actor 操作、资产管理、材质系统、行为树和黑板管理

6. mcp-tool-shop-org/game-dev-mcp

• 项目地址: https://github.com/mcp-tool-shop-org/game-dev-mcp
• 语言: TypeScript
• 特点: 使用 UE5 内置的 Remote Control API（无需第三方插件）
• 适合: 快速上手，不想编译 C++ 插件的团队

7. Codeturion/unreal-api-mcp

• 项目地址: https://github.com/Codeturion/unreal-api-mcp
• 特点: 即时、准确的 UE API 查询，节省 token

8. etelyatn/UnrealCortex

• 项目地址: https://github.com/etelyatn/UnrealCortex
• 特点: 模块化架构，支持 Blueprint → C++ 迁移

🆚 MCP vs SAL（知乎文章方案）

知乎文章《借助语义抽象层和Agent编排器在UE工程中实现工程生产可用的Vibe Engineering》提到的 SAL（Semantic-Abstract-Layer） 方案与 MCP 的对比：

结论: MCP 方案适合快速原型，SAL 方案更适合严肃工程。

🎯 选择建议

🔧 MCP 工具链优化方案

核心原则：让 LLM 像一个读过文档的开发者一样能正确使用工具。 以下六条优化方案来自 UE MCP 项目的实践经验。

优化一：Description 即接口——描述是最重要的设计

MCP 工具和普通 API 最大的区别：调用方是 LLM 而非人类。LLM 靠 description 字段判断”什么时候该调用、怎么调用”，描述写得烂，工具就是死的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# ❌ 烂的描述 —— LLM不知道什么时候用
@mcp.tool()
def set_property(name: str, value: str) -> dict:
    """设置属性"""

# ✅ 好的描述 —— LLM能自主决策
@mcp.tool()
def set_blueprint_variable(blueprint_path: str, var_name: str, value: str) -> dict:
    """
    修改蓝图中某个变量的默认值。

    适用场景：当你需要调整蓝图的初始配置（如移速、血量上限）时使用。
    注意：只修改默认值，不影响运行时已创建的实例。

    Args:
        blueprint_path: 蓝图资产路径，如 '/Game/Characters/BP_Hero'
        var_name: 变量名，大小写敏感
        value: 新的默认值（统一用字符串，工具内部做类型转换）
    Returns:
        {"success": bool, "previous_value": str, "message": str}
    """

描述要包含：做什么、什么时候用、边界限制、参数语义、返回值含义。

优化二：粒度控制——以子系统为边界

1
2
3
4
5
6
7
8
9
10
11
12
13

太细（❌）：
  create_blueprint_node_position_x()
  create_blueprint_node_position_y()
  → LLM要调几十次才完成一件事，中间容易出错累积

太粗（❌）：
  create_entire_character_blueprint(description: str)
  → 黑盒操作，出错了LLM无法定位是哪一步

合适（✅）：按UE子系统边界，每个工具做一件完整的事
  create_blueprint()            # 创建蓝图文件
  add_variable_to_blueprint()   # 添加变量
  compile_blueprint()           # 编译

以引擎子系统（Animation / Material / Blueprint 等）为边界划分服务器，每个服务器内部再分高/低两层抽象：高层提供常用工作流，低层提供灵活控制。

优化三：返回值要”对 LLM 友好”

LLM 看到返回值后要决定下一步做什么，返回值必须包含足够的决策上下文：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# ❌ 对LLM无用
return {"result": "ok"}

# ✅ LLM能据此决策下一步
return {
    "success": True,
    "asset_path": "/Game/Blueprints/BP_Enemy",
    "next_steps": "可以用 add_variable_to_blueprint 添加变量，或 compile_blueprint 直接编译",
    "warnings": []
}

# ❌ 失败时只返回 False —— LLM不知道为什么，只能重试或放弃
return {"success": False}

# ✅ 失败时告诉LLM原因，让它能自我纠正
return {
    "success": False,
    "error_type": "PATH_NOT_FOUND",
    "error_message": "路径 '/Game/Blueprints/BP_Enemy' 不存在",
    "suggestion": "请先用 list_blueprints() 查询现有蓝图路径"
}

优化四：读写分离，副作用透明

LLM 在不确定时倾向于调用”看起来安全”的工具。读写要明确分类，写操作在描述里标注副作用：

1
2
3
4
5
6
7
8

只读工具（LLM可放心调用）：
  list_blueprints()          → 查询项目中所有蓝图
  get_blueprint_variables()  → 查看蓝图变量列表

写操作工具（描述中标注副作用）：
  create_blueprint()   → "注意：会在磁盘上创建新文件"
  delete_asset()       → "注意：不可逆操作，请确认路径正确"
  compile_blueprint()  → "注意：会触发UE编译，耗时约1-3秒"

优化五：幂等性设计，让 LLM 敢于重试

LLM 可能因超时或误判而重复调用同一工具，应当设计为重复调用安全：

1
2
3
4
5
6
7

def create_blueprint(name: str, path: str) -> dict:
    existing = ue_api.find_asset(f"{path}/{name}")
    if existing:
        # 不报错，返回现有资产路径
        return {"success": True, "asset_path": existing.path,
                "note": "蓝图已存在，返回现有资产"}
    # 正常创建流程...

优化六：分层工具结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

高层工具（面向任务）：               ← 描述引导LLM优先使用
  setup_character_blueprint()       # 创建角色蓝图完整流程
  batch_import_textures()           # 批量导入贴图并自动设置材质

  ↓ 内部调用

中层工具（面向单步操作）：           ← LLM在需要精细控制时使用
  create_blueprint()
  add_component_to_blueprint()
  set_material_parameter()

  ↓ 内部调用

底层（直接 UE Python API）：        ← 一般不直接暴露给LLM
  unreal.EditorAssetLibrary.*

高层工具减少 LLM 调用次数，低层工具保证灵活性。描述里引导 LLM 优先走高层路径。

优化方案总结

在实际 UE MCP 项目中，按 14 个引擎子系统划分服务器，每个服务器内分只读查询和写操作两类工具，写操作描述里都标注了副作用，实践下来 LLM 的工具选择准确率明显提升。

📚 学习资源

• MCP 官方文档: https://modelcontextprotocol.io/
• MCP Registry: https://registry.modelcontextprotocol.io/
• flopperam 文档: https://flopperam.com/docs
• 视频教程: flopperam YouTube
• 知乎文章: 借助语义抽象层和Agent编排器在UE工程中实现工程生产可用的Vibe Engineering

🔍 搜索关键词

• unreal mcp
• unreal engine mcp server
• ue5 model context protocol
• unreal ai automation