Tool Reference

This page lists ue-mcp's own category tools and actions. For the official Unreal 5.8 tools that ue-mcp wraps (surfaced inside these same categories), see Native Tools.

UE-MCP exposes 26 category tools covering 1931+ actions, plus a flow tool for running multi-step YAML workflows. Every category tool takes an action parameter that selects the operation, plus action-specific parameters.

<!-- Heading level is deliberate. scripts/generate-tool-metadata.ts regenerates this file from ALL_TOOLS and keeps only what precedes the first ## heading, so hand-written prose that must survive a regeneration lives here and stays at ### or deeper. -->

Parameters every category tool accepts

Four parameters sit outside any one action. They are read by dispatch and stripped before the call reaches the bridge, so they can never collide with an action's own parameter of the same name, and they behave identically on every category tool.

select and omit

Some reads are large by nature. level(get_component_tree) on a character answers with every component's transform, collision, materials and tags; asset(bulk_read_properties) answers a library-wide question across hundreds of assets. An agent that wanted one field out of either still pays for all of it, and the cost lands in a context window rather than on a wire, where it cannot be recovered later in the conversation.

Both take dotted paths, and both traverse arrays transparently:

level(action="get_outliner", select="actors.name")
level(action="get_component_tree", actorName="BP_Hero", select=["components.name", "components.class"])
asset(action="get_metadata", assetPath="/Game/Hero", omit="thumbnail")

components.name keeps the name of every component in the array. components[].name means the same thing: the brackets are accepted and discarded rather than being a second syntax with different behaviour. Two paths into the same array produce one array of two-key objects, not two arrays.

select runs first and omit second, so keeping a subtree and dropping one field inside it does what it reads like.

A path that matches nothing comes back in a fieldsNotFound field on the result rather than being ignored, because the alternative failure is a caller concluding a field is absent from the data when it only misspelled the path. If no path matched, the filter is not applied at all and the full result is returned with the same report: handing back () would read as an empty answer from the editor rather than as a filter that did not fit.

timeoutMs

How long to wait for this call, in milliseconds. Omitted, the wait is 30 seconds, or longer for the actions the editor itself allows longer. Raise it for a large batch, or for an editor busy compiling shaders.

A timeout never means the call did not happen. The request was sent; only the wait ended. Read the state back before retrying.

pathsRepaired

Unreal addresses content with forward slashes, and so does every bridge handler. An agent running on Windows does not reliably produce them: it writes \Game\UI\WBP_Menu or /Game/UI\WBP_Menu, because that is what the surrounding shell, the file explorer and half its training data look like. The bridge then fails to resolve an asset that is right there, and the error says the asset does not exist, which sends the caller looking for the wrong problem.

So the server repairs it at the boundary, on any parameter whose name says it holds a path (one ending in Path, Paths, Dir, Directory, File or Folder, including every element of a list like assetPaths). Doing that silently would be worse than not doing it, so every repair comes back on the result:

{
  "pathsRepaired": {
    "note": "Backslashes were replaced with forward slashes in these parameters. Unreal addresses content with forward slashes; send them that way to avoid the repair.",
    "repairs": [{ "param": "assetPath", "from": "\\Game\\UI\\WBP_Menu", "to": "/Game/UI/WBP_Menu" }]
  }
}

Two shapes are deliberately left alone. A UNC path (\\server\share\x) keeps its leading pair, which is syntax rather than a mistake, and a parameter whose name does not say it holds a path is never touched, so a string that merely looks escaped survives intact. A Windows drive path (C:\Users\...) is repaired, because forward slashes are accepted everywhere it can be used: Node's fs layer, UBT and Unreal's own file APIs all take them.

The field only appears when something was repaired, and only on an object result. It is absent from a clean call.

Dialog handling modes

A modal dialog blocks Unreal's game thread, so nothing else runs until it is answered. Every action is refused while one is up and the refusal carries the dialog's title, message and buttons.

The dialog handling mode decides what happens next.

Who may press is enforced, not just described. editor(action='respond_to_dialog') is accepted only in auto. Under interactive and defer it comes back refused like any other action, because the answer belongs to the person: interactive asks them in a form, defer waits for them at the editor's own window. editor(action='list_dialogs') stays available in every mode, so the dialog can always be READ; only the press is withheld.

Armed policies are the exception. editor(set_dialog_policy) arms a pattern, and a dialog matching it is answered immediately, under every mode, with no elicitation and no refusal. That is the point of it: you decide the answer in advance. Nothing else presses a button on its own, and there are no built-in policies, so the list is empty until you put something in it.

Setting it. One key, read in this order (highest wins):

1. UE_MCP_DIALOG_MODE=interactive|auto|defer in the server's environment. A value that names no mode is ignored, and the result says it was ignored, so a typo cannot quietly change how dialogs are handled.
2. dialog.mode for this project in ~/.ue-mcp/state.json, set with npx ue-mcp dialog mode [mode] --editor [name].
3. dialog.mode for this user in ~/.ue-mcp/state.json, set with npx ue-mcp dialog mode [mode].
4. The default: interactive when the client advertised elicitation, otherwise defer.

The default never resolves to auto. With no channel to a person, the fallback is the one that suspends, never the one that lets something else decide. auto applies only when you name it. "Advertised elicitation" is read from the connected client's declared capabilities at call time, not from whether the server happens to have an elicitation gate, which it always does.

Never hand-edit ~/.ue-mcp/state.json; npx ue-mcp dialog mode writes it. Run it with no value to print the effective mode, the per-project value and the per-user value.

Mode is not read from ue-mcp.yml, for the reason the feedback mode is not: whether somebody is at the keyboard to answer a modal is a property of your machine and your session, not project policy a collaborator should inherit.

The gate, which is not the mode. Whatever the mode says, a modal blocking the editor stops everything else. Every action is refused while one is up, whatever raised it and whichever category is calling, and the refusal carries dialogBlocking: true, the dialog's exact title and complete message, its buttons in the dialog's own order, and the editor(action='respond_to_dialog') call for each. The refusal is identical on every action, so the only way forward is through the dialog.

One guard per editor decides this, and every route to that editor passes it: an MCP tool call, a step inside a flow, a nested flow, the HTTP flow surface, a plugin guard task, and the catalog call the server makes before it has served anything. The bridge refuses anything that needs the editor at its dispatch point, so a call no longer queues behind the parked game thread and dies on a timeout that reads like a slow editor. The in-process actions are refused by the same guard, rather than carrying on while the editor is stuck. A flow is checked at every step and not only when it starts, because a modal can appear in the middle of a run that takes minutes.

Five actions stay reachable throughout, or the dialog could never be answered: list_dialogs, respond_to_dialog, and the three *_dialog_policy actions. project(get_status) and editor(get_engine_state) stay reachable too, so a caller can always see where it stands, and start_editor, stop_editor and restart_editor stay reachable because they are how you get out of an editor that is stuck. Every one of those still reports the dialog: an allowed action is not a blind one, and a successful result taken while a modal is up is stamped editorBlockedByDialog. Nothing in the gate presses a button or ranks one.

The gate is per editor. A modal in one project does not refuse calls addressed to another.

Where the mode applies. Everywhere. Every action resolves it, so interactive puts the dialog to you whatever call tripped it, auto hands the press calls to the agent, and defer reports it for recognition and withholds them. The mode is read per call, from the same key and the same order as before.

Answering through the elicitation form frees the editor, so the call that tripped the gate runs rather than making you ask twice. Where the gate caught it after the fact, the reply says dialogAnswered: true and names the call to repeat.

editor(stop_editor) and editor(restart_editor) additionally ask the bridge whether a dialog is blocking the editor before they send anything, because they have to decide whether to send a quit at all. Every result of those two that met a dialog over the bridge reports dialogMode and dialogModeSource, whatever the call went on to do, so you can always see which mode applied and why. A dialog the user answered through the elicitation form is gone from the screen by the time the call returns, and the fields are still there, along with dialogAnsweredByUser naming the button that was pressed. When the stop then times out anyway, the report describes the editor as it is at that moment: it does not re-quote the dialog you just answered, and it never offers a respond_to_dialog call for a window that is no longer on screen.

In defer, stop_editor and restart_editor withhold the press calls on every path they report a dialog on: the check before the quit, a dialog that comes up behind the quit, a dialog seen while the bridge is unreachable, and (for restart_editor) one raised while the editor is starting back up. To answer one from here after all, read it with editor(list_dialogs) and press with editor(respond_to_dialog), which is a decision you make rather than one the payload makes for you.

Two blocking-dialog reports are mode-independent, carry no dialogMode, and press nothing under every mode: a dialog raised during editor(start_editor), where the bridge is not answering yet so there is no socket to deliver an answer on (dialogPolicy is the parameter for that case, and a caller arms it deliberately, in advance), and a dialog seen from outside while the bridge is unreachable, where respond_to_dialog cannot be delivered at all. editor(start_editor) resolves the mode like everything else and follows defer when that is what applies, as does the start half of a restart_editor.

Nothing outside these modes ever answers a dialog by itself. editor(set_dialog_policy) still exists for a caller who wants a matching prompt pre-answered and dismissed without seeing it, and every policy in effect is one somebody armed deliberately.

project

Project status and editor connection: get_status (is the editor connected?), set_project (switch/redirect the bridge to another .uproject), get_info. Also config INI files, module load state, and C++ source inspection. Call project(get_status) first in any session.

asset

Asset management: list, search, read, CRUD, import meshes/textures, datatables, stringtables.

blueprint

Blueprint reading, authoring, and compilation, including AnimGraph/EventGraph node scripting: add_node, connect_pins, search_node_types, plus variables, functions, graphs, components, interfaces, and event dispatchers.

level

Level actors, selection, components, level management, volumes, lights, and splines.

material

Materials: create, read, parameters, shading, textures, and graph authoring (expression nodes, connections).

animation

Animation assets, skeletons, montages, blendspaces, anim blueprints, physics assets.

landscape

Landscape terrain: info, layers, sculpting, weight painting, materials, splines, proxies.

pcg

Procedural Content Generation: graphs, nodes, connections, execution, volumes.

foliage

Foliage instances, types, procedural spawners, sampling and settings. Every FoliageType tunable (Density, Radius, ScaleX/Y/Z, AlignToNormal, GroundSlopeAngle, CullDistance, CastShadow) is a plain property: use set_settings, batch_set_settings_where or asset(set_property), not a typed action. Grass on landscape layers is authored elsewhere and deliberately has no action here: material(add_expression, expressionType="LandscapeGrassOutput") adds the slot node, material(list_expressions) reads it back, asset(create_asset_by_class, className="LandscapeGrassType") makes the grass type, and asset(set_property) fills its GrassVarieties.

niagara

Niagara VFX: systems, emitters, spawning, parameters, and graph authoring.

audio

Audio: sound assets, playback, MetaSound + SoundCue graph authoring, submixes/effects, sound classes/mixes, attenuation, concurrency, spatialization.

widget

UMG Widget Blueprints, Editor Utility Widgets, and Editor Utility Blueprints. One parameter contract across every action (#798): the asset is always assetPath, an Unreal package path such as /Game/UI/WBP_Example; a widget inside the tree is always widgetName; its parent panel is always parentWidgetName; arguments for the epic_* actions always go in input, and a top-level assetPath is folded into the asset reference of the wrapped tool for you. A .uasset suffix, an object suffix (.WBP_Example), backslashes, and the legacy path / widgetBlueprintPath / widgetBlueprint spellings are accepted and normalized. Create actions take assetPath too; name plus packagePath remains valid and is composed into it. See Widget parameter contract.

editor

Editor commands, Python execution, PIE, undo/redo, hot reload, viewport, performance, sequencer, build pipeline, logs, editor control.