Unreal Engine MCP Server
The Unreal Engine MCP Server exposes one unreal gateway tool that lets any MCP client (Claude, Cursor, VS Code, etc.) search, describe, and execute nearly 400 capabilities inside a running Unreal Editor via a native C++ plugin.
search– find capabilities from 2–4 plain words; each result includes a ready-to-sendnextCalldescribe– return a capability's exact contract: parameters, input/output schemas, example, and consent grantexecute– run one validated action and return the data plus a receipt of changes, handles, and warningsconfigure– enable or disable groups of internal capability tools (never touches the editor)Levels & actors – spawn/place/attach actors, transform, audit placements, load/stream/save levels
Blueprints & UI – create Blueprints, variables, components, event graphs, and UMG widget layouts
Materials & worlds – material graphs/instances, procedural textures, lighting, landscapes, foliage, Niagara, PCG
Gameplay – characters, animation, Gameplay Ability System, AI (Behavior Trees, State Trees, EQS), inventory, combat, networking, Enhanced Input
Cinematics & audio – Level Sequences, Movie Render Queue, Take Recorder, Sound Cues, MetaSounds
Play & verify – Play-In-Editor with synthetic input, viewport screenshots, log reading, profiling, Python execution, packaging
Safety – local-only by default, capability-token protected, per-call consent for destructive actions, strict parameter validation, and a
DIRECT_TOOL_CALL_REMOVEDreceipt for legacy direct tool callsTwo transports – native Streamable HTTP on port 3000 (no Node.js) or stdio via the Node.js server over WebSocket on port 8090
Enables AI assistants to control Unreal Engine via Remote Control API, providing tools for asset management, actor spawning and manipulation, level editing, animation and physics control, visual effects creation, sequencer cinematics, and console command execution for game development automation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Unreal Engine MCP Serverspawn a cube actor at the origin"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
📌 Which version is this? This README describes the 0.6 line: the
devbranch and npmunreal-engine-mcp-server@beta. The previous stable release, 0.5.30 (npmlatest), exposes 23 separate tools instead of one; see Upgrading from 0.5.x.
Contents · What it does · How it works · Quick start · The unreal tool · Configuration · Security · Engine plugins · Docker · Documentation · Development · Community
What it does
🏗️ Levels and actors Spawn one actor or hundreds in a single call, place and attach them, find the ones sunk into the floor, and load, stream and save levels.
🧩 Blueprints and UI Create Blueprints, variables and components, build whole event graphs in one batch, and lay out UMG widgets, with a preview image to check them.
🎨 Materials and worlds Material graphs and instances, procedural textures, lighting, landscapes, foliage, Niagara effects and PCG graphs.
🕹️ Gameplay Characters and animation, Gameplay Ability System, AI (Behavior Trees, State Trees, EQS), inventory, networking and Enhanced Input.
🎬 Cinematics and audio Level Sequences, cameras, Movie Render Queue and Take Recorder; Sound Cues and MetaSounds.
🧪 Play and verify Run Play-In-Editor with synthetic input, take screenshots the model can see, read logs, profile, run Python, and package builds.
Nearly 400 capabilities in all, behind a single MCP tool. The assistant finds them by searching in plain words, so nobody has to learn their names. The full list is the generated Action Reference.
Related MCP server: unreal-mcp
How it works
The MCP Automation Bridge plugin runs inside the editor and does all the work, on the editor's game thread. Clients reach it in one of two ways, and both expose the same single tool, unreal:
🌐 Route A · Native HTTP | 🧩 Route B · stdio | |
Path | Client → the plugin's Streamable HTTP server at | Client → |
Node.js | Not needed | 20.19 or later |
Capability token | The client sends it in the | Read from the project, given |
Best for | Claude Code, Cursor, VS Code, and several clients sharing one editor | Claude Desktop, and clients that only launch local commands |
Everything listens on 127.0.0.1 and requires the project's capability token unless you change it.
Quick start
The Quick Start page walks through this with screenshots. You need Unreal Engine 5.0 to 5.8 and a project with C++ code; a Blueprint-only project can use prebuilt binaries.
1. Add the plugin
Download McpAutomationBridge-plugin-<version>.zip from the newest v0.6 pre-release on the Releases page, and copy the McpAutomationBridge folder it contains into your project:
MyGame/Plugins/McpAutomationBridge/Or use a clone of this repository: copy plugins/McpAutomationBridge/, or reference the folder from your .uproject with "AdditionalPluginDirectories": ["C:/Path/To/Unreal_mcp/plugins"].
Open the project and let Unreal rebuild the plugin. When it's loaded, the status bar shows MCP off. If you see "Engine modules cannot be compiled at runtime", build the project once in Visual Studio, Rider or Xcode. More in Installation.
https://github.com/user-attachments/assets/d8b86ebc-4364-48c9-9781-de854bf3ef7d
Build the plugin once on a machine with the engine and a compiler, then hand out the zip. No compiler is needed on the target machine:
node scripts/package-plugin.mjs "C:/Program Files/Epic Games/UE_5.7"This writes build/McpAutomationBridge-v<version>-UE5.7-<Platform>.zip, where <version> is the package.json version (currently 0.6.0-beta-c). Unzip it into YourProject/Plugins/. Binaries only work with the engine minor and platform they were built for: a 5.6 build won't load in 5.5, 5.7 or 5.8.
2. Connect your client
Route A · Native HTTP (no Node.js)
In Edit › Project Settings › Plugins › MCP Automation Bridge, tick Enable Native MCP Server (port
3000by default), then restart the editor. The status bar now readsMCP :3000 (0).Read the capability token the plugin generated:
<YourProject>/Saved/MCP/capability-token. Treat it like a password.Add the server to your client and send the token in the
X-MCP-Capability-Tokenheader. Claude Code:claude mcp add --transport http unreal-engine http://127.0.0.1:3000/mcp --header "X-MCP-Capability-Token: <token>"Or in a project
.mcp.json(Claude Code), reading the token from an environment variable:{ "mcpServers": { "unreal-engine": { "type": "http", "url": "http://127.0.0.1:3000/mcp", "headers": { "X-MCP-Capability-Token": "${UNREAL_MCP_TOKEN}" } } } }Cursor (
.cursor/mcp.json) takes the sameurlandheaderswithouttype. VS Code, Windsurf and others: Connecting Clients.Check it: when the client connects, the count in the status bar goes up.
A client connected straight to /mcp loses its session whenever the editor closes or crashes, and has to reconnect by hand. The package's proxy command sits in between over stdio: while the editor is down every call answers NOT_CONNECTED, and the first call after it is back reaches it, with no reconnect. It keeps the editor's last tool list, so a session that starts before the editor still gets the real tool.
{
"mcpServers": {
"unreal-engine": {
"command": "npx",
"args": ["-y", "unreal-engine-mcp-server@beta", "proxy"],
"env": { "UE_PROJECT_PATH": "C:/Path/To/YourProject" }
}
}
}The token is found the same way as on Route B (MCP_AUTOMATION_CAPABILITY_TOKEN, else the project's token file). UNREAL_MCP_URL points it at another endpoint (default http://127.0.0.1:3000/mcp). Route B survives editor restarts the same way on its own.
Route B · stdio (Node.js 20.19+)
Add this to your client's MCP configuration, for example Claude Desktop's claude_desktop_config.json:
{
"mcpServers": {
"unreal-engine": {
"command": "npx",
"args": ["-y", "unreal-engine-mcp-server@beta"],
"env": {
"UE_PROJECT_PATH": "C:/Path/To/YourProject"
}
}
}
}UE_PROJECT_PATH (the project folder or its .uproject) is how the server finds the capability token and the plugin's port, so nothing else needs setting. Keep the @beta tag: without it, npm installs 0.5.30, which doesn't match a 0.6 plugin.
3. Try it
With the editor open, ask your assistant to "list the actors in the current level", "spawn a point light 300 units above the origin", or "take a screenshot of the viewport". If it doesn't connect, see Troubleshooting.
The unreal tool
Both routes expose exactly one MCP tool, unreal, with four operations. Only the contract the model is about to use gets loaded, instead of hundreds of tool schemas:
Operation | What it does |
| Finds capabilities from 2-4 plain words, such as |
| Returns one capability's exact contract: parameters, schemas, an example, and the consent grant when one is needed |
| Runs one capability with validated parameters and returns the data plus a receipt of what changed |
| Enables or disables groups of internal tools; never touches the editor |
A typical exchange:
{ "operation": "search", "query": "spawn actor" }{ "operation": "describe", "tool": "control_actor", "action": "spawn" }{
"operation": "execute",
"tool": "control_actor",
"action": "spawn",
"params": { "classPath": "/Script/Engine.PointLight", "actorName": "KeyLight", "location": [0, 0, 300] }
}Parameters are strict. An undeclared name is refused with
UNDECLARED_PARAMETERand the list of allowed names; every error carries an executablenextCall.Deletes need consent. 62 capabilities (all destructive ones, plus some writes) only run with the
consentGrantfromdescribe, passed back as a top-levelconsentfield.Names. Both routes accept the
tool+actionpair; the stdio route also accepts a capability id, such as"capability": "control_actor.spawn".
Full reference with real replies: Using the Gateway.
Migrating from direct tool calls
The single unreal tool is permanent on both routes; there is no opt-out and no 23-tool listing to restore. A client that still calls a canonical tool name directly (tools/call with name: "manage_asset", name: "control_actor", …) receives a bounded, copy-paste-executable DIRECT_TOOL_CALL_REMOVED receipt instead of a routed call. Its nextCall drills exactly one level: { "operation": "search" } for an unknown name, { "operation": "describe", "tool": "<tool>" } when no action was given, or { "operation": "execute", "tool": "<tool>", "action": "<action>", "params": { ... } } when the call already named an action. Run that nextCall through unreal to finish the migration. See Upgrading.
Protocol versions
Both routes negotiate the MCP protocol version at initialize. The native /mcp transport supports 2025-11-25 (latest), 2025-06-18 and 2025-03-26; the stdio server also accepts the legacy 2024-11-05 and 2024-10-07. An unsupported MCP-Protocol-Version header on the native route gets HTTP 400. Both also answer server/discover without a session, listing those versions, so a client on the newer 2026-07-28 revision falls back to initialize. Details: docs/protocol.md.
These route requests inside the gateway; clients never list them. More in the Tools Reference.
Category | Tool | Covers |
Core |
| Assets and folders, materials and material graphs, textures and render targets, data tables, structs, enums, source control |
Core |
| Blueprints, components, variables, event graphs, UMG widgets, layout, bindings, widget animations |
Core |
| Spawning, transforms, attachment, components, materials, tags, placement audits |
Core |
| Play-In-Editor, synthetic input, screenshots, viewport camera, undo, editor preferences |
Core |
| Create, load, save, stream, import and export levels; world settings; lighting builds |
Core |
| Console commands, logs, project settings, profiling, builds and packaging, tests, Python |
Core |
| Read and write any UObject's properties, components and class info |
Core |
| Which internal tools are enabled (through |
World |
| Landscapes, foliage, lights and sky, water, weather, splines, procedural terrain |
World |
| Sublevels, World Partition, streaming, data layers, HLOD, volumes |
World |
| Geometry Script meshes: booleans, deformers, UVs, collision, LODs, polygon cages, subdivision surfaces, material ids, vertex-color masks |
World |
| PCG graphs: create, add and connect nodes, execute |
Gameplay |
| Animation Blueprints, blend spaces, montages, skeletons, Control Rig and IK, ragdolls, cloth, vehicles |
Gameplay |
| Character Blueprints, movement, MetaHuman |
Gameplay |
| Weapons, projectiles, hit detection |
Gameplay |
| Niagara systems, emitters and modules, debug shapes |
Gameplay |
| Gameplay Ability System: abilities, attributes, effects |
Gameplay |
| AI controllers, Behavior Trees, EQS, State Trees, Smart Objects, perception, navigation |
Gameplay |
| Items, loot tables, crafting recipes |
Gameplay |
| Doors and other interactables |
Utility |
| Sounds, audio components, Sound Cues, MetaSounds, attenuation, mixes |
Utility |
| Level Sequences, Movie Render Queue, media, Take Recorder, replays |
Utility |
| Replication, RPCs, sessions, game framework classes, Enhanced Input |
Configuration
Most setups touch one setting: Enable Native MCP Server for Route A, or UE_PROJECT_PATH for Route B. Everything is listed on the Configuration page.
Plugin settings (Project Settings › Plugins › MCP Automation Bridge, saved in Config/DefaultGame.ini):
Setting | Default | |
Enable Native MCP Server | off | Serve MCP over HTTP at |
Native MCP Port |
| The |
Listen Ports |
| WebSocket ports for Route B |
Require Capability Token | on | Both routes refuse clients without the token |
Allow Non Loopback | off | LAN access for both listeners. See Security. |
Environment variables (Route B only, in the client's env block):
Variable | Default | |
| unset | Project folder or |
| the project's first Listen Ports entry, else | Editor WebSocket port |
|
| A LAN address also needs |
| read from the token file | Token to present, when the server can't read the project folder |
| empty | Extra content roots such as |
|
|
|
Security
Local by default. Both routes listen on
127.0.0.1only. LAN access needs Allow Non Loopback, and the native server refuses to bind off-loopback unless Require Capability Token is on.Capability token. Generated per project at
<Project>/Saved/MCP/capability-token(a value typed into Capability Token overrides it) and compared in constant time. Delete the file and restart the editor to rotate it.Consent for destructive work. Deletes and some other writes need a per-call consent grant, which the plugin checks itself.
Guard rails. Asset paths are limited to
/Game,/Engine,/Script,/Temp,/Niagaraplus configured prefixes, and a content path may also sit under a mount the connected editor reports; arguments the server treats as files (such asfilePath, andoutputPatheven where it names an asset) never use the reported mounts; console commands that chain or quit the editor are blocked; the plugin's own settings are out of reach of automation.
Details: Security. Please report vulnerabilities privately through GitHub security advisories.
Engine plugins
The bridge declares its engine-plugin dependencies, so Unreal enables them together with it.
Plugin | Used for |
Python Editor Script Plugin | Python-backed editor automation, |
Editor Scripting Utilities | Asset and actor subsystem operations |
Niagara | Visual effects |
Gameplay Abilities |
|
Smart Objects | AI smart objects |
Plugin | Used for |
Level Sequence Editor, Takes, Movie Render Pipeline, Movie Pipeline Mask Render Pass, Electra Player |
|
Control Rig, RigVM, IK Rig, Animation Data |
|
Chaos Vehicles, Chaos Cloth |
|
Niagara Editor |
|
Behavior Tree Editor, Environment Query Editor, StateTree, Mass Gameplay |
|
Geometry Scripting, Geometry Processing, Mesh Modeling Toolset, Procedural Mesh Component |
|
PCG |
|
MetaSound, Synthesis |
|
Enhanced Input, Online Subsystem, Online Subsystem Utils |
|
Interchange, Interchange OpenUSD, Data Validation, StructUtils | Import/export, validation, struct helpers |
Fab, Bridge | Fab asset library access (optional |
The plugin targets every Unreal Engine minor from 5.0 to 5.8. If it fails to build on yours, please open an issue with the build log.
Docker
The image runs the stdio server. It has to reach the editor's WebSocket on 127.0.0.1, so use host networking (Linux), and pass the token because the container can't read your project folder:
docker build -t unreal-mcp .
docker run -i --rm --network host -e MCP_AUTOMATION_CAPABILITY_TOKEN=<token> unreal-mcpUse -i without -t: a TTY corrupts the MCP stream on stdout.
Documentation
📖 Wiki | Quick Start, Installation, Connecting Clients, Using the Gateway, Configuration, Security, Troubleshooting, FAQ, Upgrading |
Every capability with its effect, scope and consent, generated from the capability records | |
The gateway contract, with the source file behind each claim | |
📡 Protocol | Transports, version negotiation, cancellation |
Scopes, consent, path gating, idempotency, refusal codes | |
Test suites and how to add cases | |
Adding an editor action: record, handler, route and tests, plus the rules for plugin code | |
🗺️ Roadmap | Development roadmap |
What changed in each release |
Development
npm install
npm run build # clean + compile TypeScript to dist/
npm run dev # run from source with ts-node
npm run lint # ESLint (CI fails on any warning)
npm run type-check # tsc --noEmit, sources and tests
npm run test:unit # Vitest unit tests (no Unreal required)
npm run test:smoke # offline mock-mode MCP check (needs built dist/)
npm run test:params # strict parameter audit
npm run registry:generate # capability records -> generated contracts, native shards, action reference
npm run registry:check # fail if generated artifacts drift
npm run manifest:check # fail if the gateway manifest drifts
npm run eval:check # search-ranking corpus
npm run version:check # all version sources agree
npm test # integration suite (needs a live Unreal Editor + bridge)The capability records in src/tools/catalog/capabilities/records/ are the single source of truth; every *.generated.* file, the plugin's MCP/Generated/ shards and the action reference are generated from them. Never hand-edit generated files. How to add a capability: Development.
CI runs, in order: ESLint (npx eslint . --max-warnings=0), type-check, unit tests, registry:check, manifest:check, headers:check, the strict parameter audit (test:params) and eval:check, then a blocking runtime dependency audit (npm audit --omit=dev --audit-level=moderate) and an informational full-tree audit. A Node 20.19 / 26 matrix adds build and test:smoke. Plugin packaging runs only when an Unreal Engine root is configured, because CI runners don't ship an engine. Release archives exclude Binaries/, Intermediate/ and Saved/.
Community
Questions, ideas, show and tell | |
🐞 Issues | Bug reports and feature requests |
Roadmap progress and priorities |
Contributing: keep pull requests small and focused, with a Conventional Commits title; include reproduction steps for bugs; follow the existing code style. See CONTRIBUTING.md.
License
MIT. See LICENSE.
Available Tools
1 toolunrealAInspect
Unreal Engine capability gateway. Search first, describe the exact contract, then execute a validated action. Use configure only to manage internal capability availability.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No | Exact canonical parent tool name returned by search or describe. | |
| limit | No | Maximum search results to return. Defaults to 12. | |
| param | No | Exact parameter name (tool-union catalog) to inspect. Requires tool and action for full drill-down; resolves the single parameter schema. Use with describe only. | |
| query | No | Search words for tools, categories, descriptions, or actions. | |
| action | No | Exact action name returned by describe. For configure, this is a manage_tools action. | |
| cursor | No | Opaque search cursor from a previous response nextCursor. Supersedes offset. | |
| domain | No | Capability domain to browse or filter by. Call describe with no selector to list domains. | |
| effect | No | Filter search results by declared behavior effect. | |
| family | No | Capability family inside a domain. Call describe with a domain to list its families. | |
| offset | No | Zero-based search result offset. Defaults to 0. | |
| params | No | Parameters for execute or configure. Keys are the action-specific parameter names returned by describe. Never include action or subAction here. | |
| consent | No | Per-call consent grant for a capability whose policy.consent is not 'none'. Bound to one capability and one call; never persisted, inherited or reused. Read the exact grant from describe.consentGrant. Use with execute only. | |
| maxBytes | No | Serialized byte ceiling for a search response. Results are dropped from the end until the response fits. | |
| operation | Yes | search finds capabilities. describe returns an exact parent-tool contract. execute runs one validated action. configure manages internal capability availability. | |
| capability | No | Exact canonical capability ID (or declared alias) returned by search, e.g. asset.import. Preferred selector for describe. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | |
| data | No | Execute payload projected against the capability's declared output schema. Same value as receipt.data, and the same location the native /mcp surface publishes. |
| tool | No | |
| error | No | |
| limit | No | |
| param | No | |
| scope | No | Catalog scope: 'tool' for a tool summary, 'union' for the tool-union parameter catalog. |
| total | No | |
| action | No | |
| domain | No | |
| family | No | |
| hashes | No | Per-record schema and content hashes from the generated catalog. |
| offset | No | |
| policy | No | |
| result | No | |
| schema | No | Full schema of the single described param. |
| actions | No | Paginated/filterable action list on tool-only describe. |
| domains | No | Bounded domain list on a catalog-level describe. |
| filters | No | Filters applied to this search. |
| hasMore | No | |
| message | No | |
| outputs | No | |
| reasons | No | |
| results | No | |
| success | Yes | |
| behavior | No | |
| families | No | Bounded family list on a domain-level describe. |
| maxBytes | No | |
| nextCall | No | Directly-invokable gateway request for guided self-correction. |
| required | No | Whether the described param is required. |
| runnable | No | False when the capability cannot currently be executed; nextCall then points at the fix. |
| drillDown | No | Example nextCall payload to drill one level deeper. |
| errorCode | No | |
| operation | Yes | |
| truncated | No | True when results were dropped to fit the byte budget. |
| capability | No | Canonical capability ID this response describes. |
| nextCursor | No | Cursor to pass back as cursor to continue a search. |
| parameters | No | Paginated/filterable compact parameter catalog on tool+action describe. |
| parentTool | No | Legacy parent tool that dispatches the described capability. |
| actionCount | No | |
| actionLimit | No | |
| deprecation | No | |
| inputSchema | No | Exact input schema of the described capability. Never a parent-tool union. |
| suggestions | No | Closest-match names for an invalid tool/action/param call. |
| actionOffset | No | |
| availability | No | Whether the capability is available, disabled or unavailable, and why. |
| capabilities | No | Bounded capability list on a family-level describe. |
| consentGrant | No | Exact consent grant this capability requires, ready to pass back as the execute call's consent sibling. Absent when policy.consent is 'none'. |
| migratedFrom | No | Legacy tool/action pair that resolved to this capability. |
| outputSchema | No | Exact output schema of the described capability. |
| actionHasMore | No | |
| parameterCount | No | |
| parameterLimit | No | |
| catalogRevision | No | Revision of the generated canonical capability catalog this response was served from. |
| parameterOffset | No | |
| availableActions | No | |
| parameterHasMore | No | |
| perActionSchemas | No | |
| resolvedFromAlias | No | Declared alias that resolved to this capability. |
| availableParameters | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not mention that execute may have side effects, that destructive capabilities require consent, or any safety or reusability constraints. The description is too terse for a tool that can trigger actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and every word adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, nested objects, output schema), the description provides the essential workflow but omits broader context like the safety implications of execute, consent requirements, or how actions are validated. The schema covers details, but the description alone is not fully complete for a gateway of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters including operation, search, describe, execute, configure, and consent. The description adds no parameter semantics beyond the schema, but the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unreal Engine capability gateway' clearly identifies it as a meta-tool for accessing capabilities, and the workflow 'Search first, describe the exact contract, then execute' clarifies its primary function. It is distinct enough even without sibling tools, though it doesn't use a specific verb+resource pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the usage order: 'Search first, describe the exact contract, then execute a validated action.' It also provides a specific exclusion: 'Use configure only to manage internal capability availability.' This is clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.5.30- First observed
unreal
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusing it with another tool. The 'unreal' gateway is the sole entry point, so agents cannot misselect between overlapping functions in the tool set.
The tool name 'unreal' is a bare noun and does not follow any verb_noun or action-oriented pattern. While there is only one tool, the name lacks consistency with typical MCP naming conventions and provides no hint of its function.
A single tool for an 'Unreal Engine capability gateway' suggests the server is covering a large domain through one catch-all interface. This feels too thin for the apparent scope, as agents would benefit from separate tools for distinct operations like execution or configuration.
The gateway description claims to support search, describe, execute, and configure, but it is unclear whether all necessary Unreal Engine operations are reachable or discoverable. The lack of explicit tool definitions creates significant gaps in the agent's ability to know what actions are available without probing the gateway repeatedly.
Maintenance
Related MCP Connectors
Turn prompts into production-ready game assets: animated characters, textures, terrain, VFX, HUD.
- mcp-serverOAuthcom.make
Give your AI agents the tools to build, manage, and run automation workflows.
Turns a phone into a camera+Bluetooth remote so AI assistants can see and control any PC.
Image and video AI tools and your own pipelines, run from any AI assistant.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to control and automate Unreal Engine through a native C++ Automation Bridge plugin. It supports a comprehensive range of tasks including asset management, actor manipulation, editor control, and blueprint graph editing.540 npm1MIT
- FlicenseCqualityDmaintenanceEnables natural language interaction with Unreal Engine, providing 127 tools across 16 subsystems for tasks like actor manipulation, asset management, blueprint creation, and more, using built-in Python and Remote Control plugins.1006-
- AlicenseAqualityDmaintenanceEnables AI assistants to interact with Unreal Engine via Remote Control API for actor, asset, level, and editor operations.2215 npmMIT
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to control Unreal Engine through a native C++ Automation Bridge plugin, supporting asset management, actor control, sequencer, and more via HTTP or WebSocket transport.540 npmMIT