UnrealMCP - A Roundup of MCP Projects for AI-Controlled Unreal Engine

Last updated: 2026-03-04

MCP (Model Context Protocol) is the bridge that lets AI assistants directly control Unreal Engine. Below are the best actively maintained UnrealMCP projects right now.

BTW:

• Claude CLI config file path: C:\Users\Eugene\.claude.json — this single file stores MCP configurations for different paths.

• Rider Copilot MCP config file location: C:\Users\Eugene\AppData\Local\github-copilot\intellij\mcp.json

• VSCode Claude Code MCP configuration:

  %APPDATA%\Code\User\settings.json (search for MCP in VSCode Settings via Ctrl+, to enable it)

  For project-level configuration in VSCode, you need a .vscode/mcp.json file in your project directory.

  File structure:

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"]
    }
  }
}

🔥 Mainstream Project Comparison

⭐ Projects

1. flopperam/unreal-engine-mcp (Semi-commercial) (Tested 🆗)

• Repo: https://github.com/flopperam/unreal-engine-mcp
• Website: https://flopperam.com/
• Stars: 532 ⭐
• Language: Python
• UE Version: 5.5, 5.6, 5.7
• Maintenance: ✅ Actively maintained (last updated: 2026-02-14)

Core strengths:

• 🎨 Full Blueprint editing (new in v0.7)
• 🏗️ World building (towns, castles, mansions, mazes)
• 🤖 Flop Agent (built-in Agent embedded in UE editor)
• 🎮 3D generation (text/image → 3D)

⚠️ Note: Semi-open-source project

• MCP Server: ✅ Fully open source
• UE Plugin: ✅ Free
• Flop Agent: Basic features free, advanced features require payment
• 3D Generation: Good quality free, High/Very High requires payment
• AI Models: Sonnet/GPT 5.2 free, Opus 4.6 requires payment

Pricing:

Best for: Teams that need full Blueprint editing, 3D generation, and a built-in Agent

2. chongdashu/TrishynVolodymyr/unreal-mcp (Most established) (Tested 🆗)

• Repo: https://github.com/chongdashu/unreal-mcp
• Stars: 1,498 ⭐ (Fork 225)
• Language: Python
• Maintenance: ✅ Actively maintained

Features:

• Largest community, most abundant resources
• Supports Cursor, Windsurf, Claude Desktop
• Basic Actor operations, materials, level editing

Limitations:

• Primarily for Blueprint analysis, cannot directly edit Blueprints
• No 3D generation capability

Best for: Teams looking to get started quickly with community support

- Note: I’m currently using the TrishynVolodymyr/unreal-mcp fork. The original chongdashu/unreal-mcp author has gone quiet for a long time. This fork targets Unreal 5.7 — I got it running and tested it, and it covers a lot of basic functionality quite comprehensively, all implemented via Python scripts. For a 5.7 project, with a bit more polish to the setup process it’s basically production-usable. I did try adapting it to a 5.6 project and failed — there’s a massive amount of API work that would need to be changed.

3. prajwalshettydev/UnrealGenAISupport (Multi-model support)

• Repo: https://github.com/prajwalshettydev/UnrealGenAISupport
• Stars: 415 ⭐
• Language: C++ (UE Plugin)

Features:

• Supports multiple LLMs: OpenAI GPT, DeepSeek, Claude, Gemini, local models
• Built-in MCP Server
• Multi-modal API support (image generation, etc.)
• Perforce / Git version control support

Best for: Teams that need to call various LLM APIs directly from within UE

4. ChiR24/Unreal_mcp (TypeScript + C++) (Broadest coverage) (Tested 🆗)

• Repo: https://github.com/ChiR24/Unreal_mcp
• Stars: 328 ⭐
• Language: TypeScript + C++
• UE Version: 5.0-5.7

Features:

• Uses UE’s native C++ Automation Bridge plugin
• Supports NPM package installation (npx unreal-engine-mcp-server)
• Dynamic type discovery
• GraphQL API support
• Docker support
• 44+ tools

Best for: Teams that need enterprise-grade features and the TypeScript ecosystem

Note: You need to start the server from within the Unreal project path — for example mine is: $env:UE_PROJECT_PATH="D:\SVN\Solution_5_6"; npx unreal-engine-mcp-server (honestly an elegantly concise way to launch things). That said, the UE plugin implementation has some serious issues — there’s a massive pile of McpAutomationBridge_XXXXX code where every single file is extremely long, making it completely unsuitable for AI-assisted maintenance.

5. GenOrca/unreal-mcp

• Repo: https://github.com/GenOrca/unreal-mcp
• Language: Python
• UE Version: 5.6+
• Features: Complete Actor operations, asset management, material system, Behavior Tree and Blackboard management

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

• Repo: https://github.com/mcp-tool-shop-org/game-dev-mcp
• Language: TypeScript
• Features: Uses UE5’s built-in Remote Control API (no third-party plugins required)
• Best for: Teams that want to get started quickly without compiling a C++ plugin

7. Codeturion/unreal-api-mcp

• Repo: https://github.com/Codeturion/unreal-api-mcp
• Features: Instant, accurate UE API lookup, saves tokens

8. etelyatn/UnrealCortex

• Repo: https://github.com/etelyatn/UnrealCortex
• Features: Modular architecture, supports Blueprint → C++ migration

🆚 MCP vs SAL (Zhihu Article Approach)

A Zhihu article titled “Achieving Production-Ready Vibe Engineering in UE Projects Using Semantic Abstract Layer and Agent Orchestration” described a SAL (Semantic-Abstract-Layer) approach. Here’s how it compares to MCP:

Conclusion: MCP is better suited for rapid prototyping; SAL is more appropriate for serious production engineering.

🎯 Selection Guide

🔧 MCP Toolchain Optimization

Core principle: Let the LLM use tools correctly, as if it had actually read the documentation. The six optimization strategies below come from hands-on experience with UE MCP projects.

Optimization 1: Description as Interface — The Most Important Design Decision

The biggest difference between an MCP tool and a regular API: the caller is an LLM, not a human. The LLM relies on the description field to decide “when to call this, and how to call it.” A bad description makes the tool dead on arrival.

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

# ❌ Bad description — LLM has no idea when to use this
@mcp.tool()
def set_property(name: str, value: str) -> dict:
    """Set property"""

# ✅ Good description — LLM can make autonomous decisions
@mcp.tool()
def set_blueprint_variable(blueprint_path: str, var_name: str, value: str) -> dict:
    """
    Modifies the default value of a variable in a Blueprint.

    When to use: when you need to adjust a Blueprint's initial configuration
    (e.g., movement speed, max health). Note: only modifies the default value —
    does not affect instances already created at runtime.

    Args:
        blueprint_path: Blueprint asset path, e.g. '/Game/Characters/BP_Hero'
        var_name: Variable name, case-sensitive
        value: New default value (always pass as string; the tool handles type conversion internally)
    Returns:
        {"success": bool, "previous_value": str, "message": str}
    """

A good description should include: what it does, when to use it, boundary conditions, parameter semantics, and what the return value means.

Optimization 2: Granularity Control — Use Subsystem Boundaries

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

Too fine-grained (❌):
  create_blueprint_node_position_x()
  create_blueprint_node_position_y()
  → The LLM has to call dozens of times to accomplish one thing, and errors accumulate along the way

Too coarse-grained (❌):
  create_entire_character_blueprint(description: str)
  → Black-box operation; when something goes wrong the LLM can't tell which step failed

Just right (✅): use UE subsystem boundaries — each tool does one complete thing
  create_blueprint()            # Create the Blueprint asset
  add_variable_to_blueprint()   # Add a variable
  compile_blueprint()           # Compile

Divide servers by engine subsystem (Animation / Material / Blueprint, etc.). Within each server, provide two layers of abstraction: high-level for common workflows, low-level for fine-grained control.

Optimization 3: LLM-Friendly Return Values

The LLM looks at the return value to decide what to do next. The return must include enough decision context:

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

# ❌ Useless to the LLM
return {"result": "ok"}

# ✅ LLM can decide the next step from this
return {
    "success": True,
    "asset_path": "/Game/Blueprints/BP_Enemy",
    "next_steps": "You can now use add_variable_to_blueprint to add variables, or compile_blueprint to compile directly",
    "warnings": []
}

# ❌ On failure, just returning False — LLM doesn't know why; can only retry or give up
return {"success": False}

# ✅ On failure, tell the LLM why so it can self-correct
return {
    "success": False,
    "error_type": "PATH_NOT_FOUND",
    "error_message": "Path '/Game/Blueprints/BP_Enemy' does not exist",
    "suggestion": "Use list_blueprints() first to query existing Blueprint paths"
}

Optimization 4: Separate Reads from Writes, Make Side Effects Transparent

When uncertain, an LLM tends to call tools that “look safe.” Read and write operations should be clearly classified, with side effects explicitly noted in write tool descriptions:

1
2
3
4
5
6
7
8

Read-only tools (LLM can call freely):
  list_blueprints()          → List all Blueprints in the project
  get_blueprint_variables()  → View the Blueprint's variable list

Write tools (note side effects in description):
  create_blueprint()   → "Note: creates a new file on disk"
  delete_asset()       → "Note: irreversible operation, confirm the path is correct"
  compile_blueprint()  → "Note: triggers UE compilation, takes approximately 1-3 seconds"

Optimization 5: Idempotent Design — Let the LLM Dare to Retry

An LLM may call the same tool multiple times due to timeout or misjudgment. Tools should be safe to call repeatedly:

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:
        # Don't error — return the existing asset path instead
        return {"success": True, "asset_path": existing.path,
                "note": "Blueprint already exists, returning existing asset"}
    # Normal creation flow...

Optimization 6: Layered Tool Structure

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

High-level tools (task-oriented):               ← Descriptions guide LLM to prefer these
  setup_character_blueprint()       # Full flow to create a character Blueprint
  batch_import_textures()           # Batch import textures and auto-set materials

  ↓ internally calls

Mid-level tools (single-step operations):       ← LLM uses when fine-grained control is needed
  create_blueprint()
  add_component_to_blueprint()
  set_material_parameter()

  ↓ internally calls

Low-level (direct UE Python API):               ← Generally not exposed directly to the LLM
  unreal.EditorAssetLibrary.*

High-level tools reduce LLM call count; low-level tools preserve flexibility. Guide the LLM toward the high-level path in your descriptions.

Optimization Summary

In a real UE MCP project, dividing servers across 14 engine subsystems and categorizing tools within each server into read-only queries and write operations — with side effects documented in write tool descriptions — resulted in a noticeably higher LLM tool-selection accuracy in practice.

📚 Learning Resources

• MCP Official Docs: https://modelcontextprotocol.io/
• MCP Registry: https://registry.modelcontextprotocol.io/
• flopperam Docs: https://flopperam.com/docs
• Video Tutorials: flopperam YouTube
• Zhihu Article: Achieving Production-Ready Vibe Engineering in UE Projects Using Semantic Abstract Layer and Agent Orchestration

🔍 Search Keywords

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