Skip to content

Upgrading

ChiR24 edited this page Sep 30, 2026 · 6 revisions

Help · Upgrading: from 0.5.x to one tool

Moving from 0.5.x to the 0.6 line. Your old action names keep working, but they now go through a single tool.

🧭 One tool
The 23 tools (manage_asset, control_actor, …) became internal. Clients see one tool, unreal, and call the old actions through it.

🧾 Strict parameters
Parameter names must match the contract exactly. Unknown ones are refused with a list of the allowed names.

✋ Consent for deletes
Deletes, and some other writes, need a consent grant in each call.

The full list of changes is in the changelog, under each release's Migration section.

Checklist

  • Update the plugin. Close the editor, replace Plugins/McpAutomationBridge/ with the 0.6 version, reopen and let it rebuild (📦 Installation).
  • Update the server, or drop it. On the stdio route, change the package in your client config to unreal-engine-mcp-server@beta, or to the exact version of your plugin. The native HTTP route needs no Node.js at all (🔌 Connecting Clients).
  • Check Node.js. The stdio server needs 20.19 or later; Node 18 is no longer supported.
  • Remove settings that no longer exist (table below). They're ignored, so nothing breaks, but they mislead the next reader.
  • Update your own scripts, clients and prompts that name the old tools. For a model, one line usually does it: "use the unreal tool: search, then describe, then execute".
  • Add the token header to native HTTP clients if you came from before 0.5.30, when tokens were off by default (🔐 Security).

Warning

Don't mix versions. A 0.5.30 server with a 0.6 plugin, or the other way round, is not supported.

Calls: before and after

❌ 0.5.x: a direct call to a tool

{
  "name": "control_actor",
  "arguments": {
    "action": "spawn",
    "classPath": "/Script/Engine.PointLight",
    "actorName": "KeyLight"
  }
}

✅ 0.6: the same call through unreal

{
  "name": "unreal",
  "arguments": {
    "operation": "execute",
    "tool": "control_actor",
    "action": "spawn",
    "params": {
      "classPath": "/Script/Engine.PointLight",
      "actorName": "KeyLight"
    }
  }
}
  • The parameters move into params, and action never goes inside params.
  • tool and action keep their old values, so existing action names carry over. The stdio route also accepts the capability id instead, as "capability": "control_actor.spawn".

An old-style call isn't executed. It answers with a migration receipt whose nextCall is the converted request, ready to send:

{
  "success": false,
  "errorCode": "DIRECT_TOOL_CALL_REMOVED",
  "message": "Direct tool calls are removed. Call the 'unreal' gateway with operation 'execute' to run 'manage_asset.list'.",
  "nextCall": { "operation": "execute", "tool": "manage_asset", "action": "list", "params": { "path": "/Game" } }
}

An unknown tool name gets nextCall: { "operation": "search" }, and a known tool without an action gets a describe of that tool. There is no switch to bring the 23-tool listing back.

Behavior you'll notice

0.5.x 0.6
🧾 Unknown or misspelled parameters were often ignored Refused with UNDECLARED_PARAMETER, listing the allowed names. Names must match describe exactly.
✋ Deletes ran on request 62 capabilities need a consent grant in the call (🔐 Security)
🗂️ Hundreds of separate actions Related actions are folded into families with a selector (kind, edit, …). Old names still resolve and fill in the selector for you (🧰 Tools Reference).
🎯 Some actions reported success without doing the work Those actions were fixed or removed. A removed action answers UNKNOWN_ACTION with a suggestion.
📋 Partial work could report success Partial results are failures that list what happened (DELETE_PARTIAL, PARTIAL_FAILURE). spawn with a missing mesh fails with MESH_NOT_FOUND instead of spawning an empty actor.
🧰 Tools could be listed and hidden per client The listing is always the one unreal tool. configure still enables or disables internal tools, and all 23 start enabled.

Individual parameter renames (for example sublevelPath to subLevelPath on manage_level) are listed per release in the changelog. describe always shows the current names.

Settings that no longer exist

Setting Removed in Notes
MCP_GATEWAY_MODE (env) 0.6.0-beta-a The gateway is permanent
Enable Native Gateway (bEnableNativeGateway) 0.6.0-beta-a Same
WASM_ENABLED (env) 0.5.19 WebAssembly support was removed
ASSET_LIST_TTL_MS, MCP_DEFAULT_CATEGORIES, MCP_ROUTE_STDOUT_LOGS (env) after 0.6.0-beta-b Logs always go to stderr; all tool categories start enabled
MCP_METRICS_PORT and the Prometheus endpoint after 0.6.0-beta-b Diagnostics are in the ue://health resource
MCP_AUTOMATION_CLIENT_MODE, MCP_AUTOMATION_WS_PORTS, MCP_AUTOMATION_SERVER_LEGACY, MCP_AUTOMATION_MAX_AUTOMATION_REQUESTS_PER_MINUTE (env) after 0.6.0-beta-b The plugin always listens; the stdio server always dials it
Plugin: LogVerbosity, bApplyLogVerbosityToAll, bEnableSocketTelemetry, HeartbeatIntervalMs, EndpointUrl, ClientPort after 0.6.0-beta-b The plugin's WebSocket client mode is gone

"After 0.6.0-beta-b" means the change is on the dev branch and ships in the next release.

Ports and defaults

Now
WebSocket listener Still 8090 and 8091. The stdio server dials the first port in the project's Listen Ports (found through UE_PROJECT_PATH), or 8090. A config that pins MCP_AUTOMATION_PORT=8091 keeps working.
Native HTTP server Still off by default, on port 3000
Capability token Required by default since 0.5.30

🏠 Home

Get started
🚀 Quick Start
📦 Installation
🔌 Connecting Clients

Use it
🧭 Using the Gateway
🧰 Tools Reference
📚 Resources and Prompts

Set it up
⚙️ Configuration
🔐 Security

Help
🩺 Troubleshooting
💬 FAQ
⬆️ Upgrading from 0.5.x

Contribute
🛠️ Development


Covers the 0.6 line · Releases · Discussions

Clone this wiki locally