Provides tools for driving a running Unreal Engine editor, including listing assets and actors, importing assets, spawning and manipulating actors, controlling the viewport, taking screenshots, saving all, and executing arbitrary Python code in the editor.
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-mcp Take a screenshot of the current level and save it to Desktop"
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.
An MCP server that drives a running Unreal Engine editor from Claude.
It speaks Epic's own Python Remote Execution protocol:
UDP multicast on 239.0.0.1:6766 to discover editor instances, then a TCP channel to run Python inside the editor.
Claude ──stdio──▶ unreal-mcp ──UDP discovery + TCP──▶ Unreal Editor (PythonScriptPlugin)The client half of the protocol is not vendored. The server locates Epic's
remote_execution.py inside your engine install at runtime, so it keeps working
across engine versions.
Unreal Engine 5.x (developed against 5.6)
Python 3.10+ and uv
Related MCP server: unreal-mcp
Remote execution is OFF by default. Without it the editor is invisible to discovery and every tool will fail.
Edit > Plugins → enable Python Editor Script Plugin → restart.
Edit > Project Settings > Plugins > Python → tick Enable Remote Execution.
Restart the editor.
cd unreal-mcp
uv syncAdd to claude_desktop_config.json:
{
"mcpServers": {
"unreal": {
"command": "uv",
"args": ["--directory", "E:\\Maya\\unreal-mcp", "run", "unreal-mcp"]
}
}
}Then start a new conversation — servers added mid-session are not picked up by a chat that is already running.
If your engine is somewhere non-standard, set UNREAL_ENGINE_ROOT:
"env": { "UNREAL_ENGINE_ROOT": "D:\\Epic\\UE_5.6" }Tool | Read-only | What it does |
| ✅ | Is an editor reachable? Which project, level, actor count. Start here when anything fails. |
| ✅ | Browse the content browser, filtered and paginated |
| ✅ | Actors in the open level with their transforms |
| Import FBX / OBJ / textures via the automated pipeline | |
| Place a content asset into the level | |
| Move / rotate / scale a placed actor | |
| Destructive — destroys an actor | |
| Aim the editor viewport | |
| High-res PNG of the viewport | |
| Save modified assets and the level | |
| Escape hatch: arbitrary Python in the editor |
Listing tools paginate with limit / offset and return has_more plus
next_offset.
Tool bodies are shipped to the editor wrapped in a harness that assigns to a
result variable and prints it as JSON between sentinels. That keeps a stray
print() or an Unreal log line from corrupting the payload, and turns an
exception inside the editor into a structured error instead of a traceback
buried in stdout.
unreal_execute_python runs unsandboxed code in the editor's interpreter
with full unreal module access. It can modify or delete project content. Treat
it with the same care as a Python console in the editor itself.
"No running Unreal Editor was discovered" — almost always the Enable Remote
Execution setting above. Confirm with unreal_get_status.
"Lost the connection ... while running a command" — the editor was closed or is blocked in a modal dialog. Dismiss the dialog and retry; the session re-discovers automatically.
Multiple editors open — the first discovered node wins.
unreal_get_status lists them all so you can tell which is which.
Permanently remove an actor from the current level.
This is destructive. The actor is destroyed in the editor world; recovering
it requires an undo inside Unreal, which this server cannot trigger. Confirm
the intended target with unreal_list_actors before calling.
Args: params (DeleteActorInput): Validated input containing: - actor (str): Label or path identifying the actor to destroy
Returns: str: JSON confirming the removal: { "deleted": bool, "label": str, # Label of the actor that was destroyed "path": str # Its former path } On failure: "Error: "
Examples: - Use when: the user explicitly asks to remove a placed object - Don't use when: you only want to hide it, or when unsure which actor the label refers to (list them first)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: it warns this is destructive, notes that recovery requires an undo which the server cannot trigger, and advises confirming the target. This covers consequences and mitigation, exceeding the basic destructiveHint.
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?
Well-structured with clear sections (warning, args, returns, examples). The critical warning is front-loaded, and every sentence serves a purpose without redundancy.
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?
For a single-parameter destructive action, the description covers the action, consequences, usage rules, return format, and error handling. It is complete for an agent to call correctly without further assumptions.
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?
The description explains the 'actor' parameter as 'Label or path identifying the actor to destroy' and references using unreal_list_actors for confirmation. Though the schema already has a similar description, the tool description adds the safety context of verifying the target before destruction.
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 states a specific verb ('remove') and resource ('actor from the current level'), clearly distinguishing from siblings like unreal_list_actors (listing) and unreal_spawn_actor (creation). It is not a tautology and conveys a precise action.
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?
Explicitly provides when-to-use ('user explicitly asks to remove a placed object') and when-not-to-use ('only want to hide it, or when unsure which actor'), and directs the agent to unreal_list_actors for disambiguation. This is model guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run arbitrary Python inside the running Unreal Editor.
This is the general-purpose escape hatch for anything the dedicated tools do not cover. Prefer a specific tool when one exists, because those return structured data while this returns raw console output.
The code runs in the editor's own interpreter with full access to the
unreal module, so it can modify or delete project content. It is not
sandboxed.
Args: params (ExecuteInput): Validated input containing: - code (str): Python source to run - evaluate (bool): True for single-expression evaluation (default False)
Returns: str: JSON with the following schema: { "success": bool, # False if Unreal reported the command as failed "result": str, # Value for evaluate=True, else Unreal's status string "output": str # Everything the script printed / logged } On failure: "Error: "
Examples: - Use when: "how many static meshes are in /Game/Props?" -> code that counts them and prints the number - Use when: calling an unreal API no other tool exposes - Don't use when: listing actors or assets (use unreal_list_actors / unreal_list_assets, which paginate and return structured fields)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the code 'can modify or delete project content' and is 'not sandboxed', which is consistent with the destructiveHint annotation. It adds valuable context by explaining the return value behavior ('returns raw console output' vs structured data) and hinting at the risk profile. While annotations already flag destructiveness, the description's blunt warning about the ability to 'modify or delete project content' is a strong, behavior-informing disclosure. It doesn't detail specific permission requirements, but for an escape-hatch tool in this context, the warning is quite potent.
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?
The description is perfectly structured and incredibly efficient, mixing a strong opening statement, a crisp warning, and a helpful 'Args:' and 'Examples:' breakdown. Every section earns its place, front-loading the purpose and crucial safety warning before diving into parameter semantics. It's a model of clarity and conciseness.
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?
For an 'escape hatch' tool, the description provides exactly what's needed to use it correctly and safely. It clearly states the return schema (including success/result/output structure and error format), the difference between evaluate modes, and the all-important 'don't use this if a dedicated tool exists' guidance. Given its role as a fallback, the clarity on side effects and return format is complete and sufficient.
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?
The schema description coverage is reported at 0%, meaning the description itself must carry the semantic weight. The description names the parameters ('code', 'evaluate') and gives a high-level summary of each. For instance, it contrasts 'single-expression evaluation' with 'validated input'. While it adds meaning, it's not exceptionally deep about the exact string semantics beyond what the schema's 'description' fields could hold. Since schema coverage is 0%, this is better than average but doesn't fully compensate for the lack of schema semantics, placing it at a solid 3.
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 clearly states the tool 'Run arbitrary Python inside the running Unreal Editor' and explicitly frames it as a 'general-purpose escape hatch', which strongly distinguishes it from siblings. It reinforces this by naming the specific siblings it is not ('unreal_list_actors / unreal_list_assets') and what makes them different (structured, paginated data).
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?
Provides explicit guidance on when to use ('how many static meshes are in /Game/Props?', 'calling an unreal API no other tool exposes') and, crucially, when not to use it ('Don't use when: listing actors or assets') with reasons why alternatives are superior. It also states 'Prefer a specific tool when one exists' as a general rule, which is an explicit routing directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a running Unreal Editor is reachable, and describe it.
Call this first when any other tool fails, to distinguish "the editor is not listening" from "the script had a bug". Discovery is UDP multicast, so an editor that is open but has remote execution disabled will NOT appear.
Args: params (StatusInput): Validated input containing: - wait_seconds (float): Discovery listen window, 0.5-15.0 (default 2.0)
Returns: str: JSON with the following schema: { "connected": bool, # True if at least one editor answered "node_count": int, # Number of editor instances discovered "nodes": [ # One entry per editor instance { "node_id": str, # Internal session id "user": str, # OS user running the editor "machine": str, # Host name "engine_version": str, # e.g. "5.6.0-..." "engine_root": str, # Engine install path "project_name": str, # Loaded project "project_root": str # Project directory on disk } ], "live_check": { # Present only when connected "engine_version": str, "project_file": str, "current_level": str, "actor_count": int } } On failure: "Error: "
Examples: - Use when: another tool returned a connection error and you need the cause - Use when: confirming which project the editor currently has open - Don't use when: you already know the editor is connected and want to run code (use unreal_execute_python instead)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context: UDP multicast discovery, the fact that editors with remote execution disabled won't appear, and the structured error message. It does not contradict annotations.
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?
The description is long but well-structured: purpose, when-to-use, args, returns, examples. Every section serves a purpose; the return schema is essential because no separate output schema exists. It is thorough without being redundant.
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?
For a diagnostic tool with a complex output and specific behavior, the description covers everything: purpose, usage context, parameter semantics, full return structure, error format, and examples. Nothing an agent needs to call it correctly is missing.
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?
The schema already provides a description for wait_seconds ('How long to listen...'), and the description repeats it with the phrase 'Discovery listen window' and range. This adds minor semantic framing (discovery vs. general listen) but mostly restates schema info, so it meets the baseline for high schema coverage.
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 opens with a concrete verb and resource: 'Check whether a running Unreal Editor is reachable, and describe it.' It also differentiates itself from siblings by stating to call first when other tools fail, distinguishing connection issues from bugs. This clearly sets the tool apart from execution or asset tools.
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?
Explicitly states when to use: after another tool returns a connection error, or to confirm which project is open. Gives a must-not use case: when already connected and wanting to run code, with the alternative 'unreal_execute_python' named. This leaves no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a file from disk (FBX, OBJ, texture) into the project's content browser.
Runs Unreal's automated import pipeline, so no import dialog appears. With
replace_existing=True this overwrites an asset of the same name in the
destination folder.
Args: params (ImportAssetInput): Validated input containing: - source_file (str): Absolute path to the file on disk - destination_path (str): Content folder, must start with /Game - replace_existing (bool): Overwrite same-named assets (default True) - save (bool): Save to disk right away (default True)
Returns: str: JSON with the following schema: { "imported_count": int, # Number of assets created "imported": [str], # Object paths of the new assets "destination": str # Folder they landed in } On failure: "Error: " — including a clear message when the source file does not exist on the machine running the editor.
Examples: - Use when: "bring this FBX into Unreal" -> source_file set to the .fbx - Use when: staging a model before placing it with unreal_spawn_actor - Don't use when: the asset is already in the project (use unreal_list_assets)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the no-dialog behavior, overwrite semantics of replace_existing, error message format, and the fact that the source file must exist on the editor machine. This is substantial context. Missing some potential side effects (e.g., what happens on failed import beyond error message), but overall solid.
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?
The description is well-structured with Args, Returns, and Examples sections, and key behavior (no dialog, overwrite) is front-loaded. It is relatively long but information-dense; the examples clarify use cases. Could be slightly tighter, but structure aids scanning.
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?
Covers purpose, parameters, return schema, error handling ('Error: <message>' when source missing), and usage guidance with sibling differentiation. For an import operation with no annotations provided, this description fully equips an agent to decide when to call it, what arguments to provide, and what to expect in return.
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?
All four parameters (source_file, destination_path, replace_existing, save) are described with types and meaning. Adds the /Game requirement for destination_path and the default True for replace_existing and save, which the schema does not state. Return schema is also documented with counts and destination. This goes well beyond the schema alone.
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 states a specific verb ('import'), resource ('file from disk into the project's content browser'), and scope ('Runs Unreal's automated import pipeline'). It also distinguishes itself from siblings by explicitly naming what it is not (use unreal_list_assets when already in project, use unreal_spawn_actor for placing).
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?
Provides explicit when-to-use and when-not-to-use guidance: 'Use when: bring this FBX into Unreal' and 'Don't use when: the asset is already in the project (use unreal_list_assets)'. It also mentions a sibling tool (unreal_spawn_actor) for a follow-up action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List actors placed in the currently open level, with their transforms.
The label field is what other actor tools accept as an identifier, and is
what the user sees in the World Outliner.
Args: params (ListActorsInput): Validated input containing: - name_filter (Optional[str]): Substring match on the actor label - class_filter (Optional[str]): Substring match on the actor class - limit (int): Max results, 1-500 (default 50) - offset (int): Results to skip (default 0)
Returns: str: JSON with the following schema: { "total": int, "count": int, "offset": int, "has_more": bool, "next_offset": int | None, "items": [ { "label": str, # Outliner name, use this as an identifier "path": str, # Unique full path "class": str, # e.g. "StaticMeshActor" "location": [float, float, float], # X, Y, Z in cm "rotation": [float, float, float], # pitch, yaw, roll in degrees "scale": [float, float, float] } ] } On failure: "Error: "
Examples: - Use when: "what's in this level?" -> no filters - Use when: finding the exact label to pass to unreal_set_actor_transform - Don't use when: looking for unplaced content (use unreal_list_assets)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and non-destructive safety information. The description adds important behavioral context beyond that: it operates on the currently open level, the label field is the identifier other actor tools accept, and it specifies both the success JSON schema and the 'Error: <message>' failure format.
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?
The description is well-structured and front-loaded with the core purpose. The Args, Returns, and Examples sections each earn their place, and there is no filler or tautology. Despite being detailed, every sentence serves a practical purpose for correct invocation.
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?
The description covers scope, filtering, pagination, output schema, error format, and cross-tool identifier semantics. It also includes usage examples that tie into sibling tools. Nothing needed to call this tool correctly is missing.
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?
The description documents all nested parameters inside the params object, including substring match semantics, limits, defaults, and offsets. Although the JSON schema already describes these fields, the description packages them in a tool-ready way and adds the crucial note that the label field is used as an identifier by other actor tools.
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 opens with a specific verb and resource: 'List actors placed in the currently open level, with their transforms.' This clearly distinguishes it from sibling tools such as unreal_list_assets, unreal_spawn_actor, and unreal_delete_actor, so an agent can select it confidently.
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 Examples section explicitly states when to use the tool ('what's in this level?', finding a label for unreal_set_actor_transform) and when not to use it ('looking for unplaced content (use unreal_list_assets)'). This gives an agent direct routing guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List assets in the project's content browser, with filtering and pagination.
Use this to find the object path of an asset before spawning it into a level.
Returns paths in Unreal's /Game/... form, which is what
unreal_spawn_actor expects.
Args: params (ListAssetsInput): Validated input containing: - directory (str): Content path to list (default '/Game') - recursive (bool): Recurse into subfolders (default True) - name_filter (Optional[str]): Case-insensitive substring match - limit (int): Max results, 1-500 (default 50) - offset (int): Results to skip (default 0)
Returns: str: JSON with the following schema: { "total": int, # Assets matching the filter "count": int, # Assets in this page "offset": int, "has_more": bool, "next_offset": int | None, "items": [ { "name": str, # Asset name (e.g. "SM_Chair") "path": str, # Object path for loading (e.g. "/Game/Props/SM_Chair") "class": str # Asset class (e.g. "StaticMesh", "Material") } ] } On failure: "Error: "
Examples: - Use when: "what meshes did my FBX import create?" -> directory of the import - Use when: you need an asset path to pass to unreal_spawn_actor - Don't use when: you want actors placed in the level (use unreal_list_actors)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations (`readOnlyHint: true`, `idempotentHint: true`, `destructiveHint: false`) establish the safety profile, and the description's pagination details ('has_more', 'next_offset') and 'On failure: "Error: ..."' add useful behavioral context. However, the ReadOnly flag is carried by the annotation, so the description's incremental value is moderate—pagination behavior is helpful but not essential for safety, and the format is largely encoded in the output schema.
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?
The description is easy to scan with clear blocks: a concise opening, 'Use this to' usage, a detailed but structured output schema, and a 'Don't use when' conclusion. The code blocks break up the length, avoiding a wall of text while keeping only functional content.
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?
The description covers the primary use case (finding the object path), the output schema (with pagination and error handling), and the boundary condition ('Don't use when: actors in level'), covering the essential bases. The only minor gap is a few edge cases (e.g., invalid input) that are left to the schema to hint at, but nothing critical is missing.
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?
The `<input-schema>` provides detailed descriptions, types, and defaults for all five parameters, so the semantics are already well-covered by the schema. The description's 'Params' section and examples (e.g., ': default 50') add no meaningful lift beyond the schema, giving a solid baseline of 3 with no reason to boost or penalize.
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 opening statement 'List assets in the project's content browser, with filtering and pagination' is a precise verb+resource pairing, while 'Use this to find the object path of a asset before spawning it into a level' gives the precise context. It sharpens the focus without ambiguity, and the contrast with `unreal_spawn_actor (naming the sibling explicitly) makes the boundary clear.
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 opening 'Use this to' explains when to apply it, and the 'Don't use when: you want actors placed in the level (use unreal_list_actors)' names the sibling and the condition that selects it. This is the gold standard for when-to-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save every modified asset, and optionally the open level, to disk.
Writes to the project on disk. Running it twice with nothing changed in between is harmless.
Args: params (SaveInput): Validated input containing: - save_level (bool): Also save the open level (default True)
Returns: str: JSON with the outcome: { "saved": bool, # False if the user cancelled a save prompt "save_level": bool # What was requested } On failure: "Error: "
Examples: - Use when: finishing a batch of spawns or imports the user wants kept - Don't use when: the user is still experimenting and may want to discard
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the idempotentHint annotation, the description discloses that the operation writes to the project on disk, is harmless to repeat when nothing changed, and can be cancelled by the user resulting in saved=false. This adds meaningful behavioral context beyond what annotations alone provide.
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?
The key purpose is stated in the first sentence, followed by compact and relevant notes on behavior, arguments, return format, and usage. Every section adds value, and there is no redundant filler.
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?
The description covers purpose, persistence behavior, idempotence, parameter meaning, return payload including cancellation, failure indication, and when to use/discard. There is no missing piece needed for an agent to invoke this tool correctly.
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?
The description repeats the parameter meaning already present in the schema ('save_level: Also save the open level (default True)') without adding new details such as behavior when false or edge cases. Since the schema documents the single parameter adequately, no additional compensation is needed.
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 states a specific verb ('save') and resource ('every modified asset, and optionally the open level'), making its function unambiguous. It clearly distinguishes from sibling tools like list, import, spawn, and delete without any ambiguity.
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?
Explicit when-to-use and when-not-to-use guidance is provided ('Use when finishing a batch of spawns or imports...', 'Don't use when the user is still experimenting...'). It does not name a specific sibling alternative, but the contextual direction is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the location, rotation and/or scale of an actor already in the level.
Any field left as None keeps its current value, so this can nudge one axis of a transform without disturbing the rest. Setting the same values twice has no additional effect.
Args: params (SetTransformInput): Validated input containing: - actor (str): Label or path identifying the actor - location (Optional[list[float]]): New [X, Y, Z] in cm - rotation (Optional[list[float]]): New [pitch, yaw, roll] in degrees - scale (Optional[list[float]]): New [X, Y, Z] multipliers
Returns: str: JSON describing the actor after the change, same schema as unreal_spawn_actor. On failure: "Error: " — including the hint to list actors when the label does not resolve.
Examples: - Use when: "raise the camera rig 200 units" -> location with new Z - Don't use when: creating a new copy (use unreal_spawn_actor)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, and the description reinforces this with 'Setting the same values twice has no additional effect'. It also discloses the None-keeping behavior ('Any field left as None keeps its current value') and the error format ('Error: <message>') including a hint to list actors. This adds meaningful operational context beyond the annotations.
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?
The description is well-structured: the core action is front-loaded, followed by a concise note on None behavior, an Args section mapping parameters, a Returns section with error handling, and clear usage examples. Every sentence serves a purpose, and the content is organized for quick scanning.
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?
The description covers the tool's purpose, parameter semantics, idempotency, None behavior, return format (referencing unreal_spawn_actor's schema), and failure handling. It does not explicitly mention prerequisites like requiring an actor to exist, but the error hint partially addresses that. Given that an output schema exists (though not shown in the input), the description is sufficiently complete for an agent to call the tool correctly.
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?
The input schema already includes per-parameter descriptions with units (e.g., 'New world location [X, Y, Z] in cm'), so schema coverage is high. The description adds the None-keeping semantics and clarifies that omission leaves fields unchanged, which is not explicitly stated in the schema. It also provides a concrete example of partial modification ('raise the camera rig 200 units' -> location with new Z), reinforcing parameter usage.
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 states a clear, specific action ('Change the location, rotation and/or scale of an actor already in the level') and distinguishes itself from sibling tools like unreal_spawn_actor (creation) and unreal_delete_actor (removal). It explicitly notes the tool modifies an existing actor, leaving no ambiguity about its function.
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 provides direct usage guidance with concrete examples: 'Use when: "raise the camera rig 200 units"' and 'Don't use when: creating a new copy (use unreal_spawn_actor)'. It names the alternative tool and the condition that selects it, leaving no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move the editor's perspective viewport camera to a specific pose.
Affects only the editor view, not any CameraActor in the level and no saved
project data. Pair with unreal_take_screenshot to capture a chosen angle.
Args: params (ViewportCameraInput): Validated input containing: - location (list[float]): Camera position [X, Y, Z] in cm - rotation (list[float]): Camera orientation [pitch, yaw, roll] degrees
Returns: str: JSON with the camera pose actually applied: { "location": [float, float, float], "rotation": [float, float, float] } On failure: "Error: "
Examples: - Use when: framing a shot before unreal_take_screenshot - Don't use when: you want a camera the level keeps (spawn a CameraActor)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide idempotentHint=true, readOnlyHint=false, and destructiveHint=false, so the safety profile is clear. The description adds genuinely useful side-effect disclosure: it doesn't persist data or affect saved project state, and it affects only the editor view. However, it fails to disclose viewport focus/selection behavior, what happens if a shot is taken while the viewport is in a different mode, or whether the operation clamps out-of-bounds rotations, which would be richer behavioral context. The downside of dropping focus to the viewport is undisclosed.
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?
The description is well-structured and front-loaded, with the core action in the first sentence. The Args/Returns/Examples layout makes it skimmable and each section has a purpose, though the return JSON block is verbose and duplicates what the output schema already provides.
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?
For a tool with only one parameter, the description covers the essentials: purpose, parameters, return shape, and error behavior. The inclusion of an example usage ('framing a shot before unreal_take_screenshot') adds real workflow context, but it falls short of addressing the broader execution-context race conditions that tools in a rendering pipeline like this face.
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?
The description repeats the params (location, rotation) and their units and coordinate systems, which mirrors what the schema already documents. With schema description coverage at 0% in the formal sense, this repetition is somewhat helpful but not additive. It adds the clarification that the return value is the 'pose actually applied,' but the echo of both schema and return adds bulk without delivering new semantic richness.
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 leads with a specific verb-resource pair: 'Move the editor's perspective viewport camera to a specific pose,' which directly names the target, scope, and action. It explicitly contrasts with CameraActor manipulation, making it clear this does not touch level cameras. The distinction from siblings like unreal_take_screenshot and unreal_spawn_actor is clearly drawn.
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 Examples section names an 'instead' condition (when not to use it: 'you want a camera the level keeps') and names the alternative (spawn a CameraActor), which is good usage guidance. However, since the Unreal MCP API has no well-known Sandbox convention analogous to filesystem MCP, the guidance to look before you leap falls a bit flat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place an existing content asset into the current level as a new actor.
Each call creates a new actor, so calling it twice spawns two copies. Get
valid asset_path values from unreal_list_assets.
Args: params (SpawnActorInput): Validated input containing: - asset_path (str): Content path of the asset to place - location (list[float]): [X, Y, Z] in centimetres (default origin) - rotation (list[float]): [pitch, yaw, roll] in degrees - scale (list[float]): [X, Y, Z] multipliers - label (Optional[str]): Outliner name for the actor
Returns: str: JSON describing the created actor: { "label": str, "path": str, "class": str, "location": [float, float, float], "rotation": [float, float, float], "scale": [float, float, float] } On failure: "Error: " — including a clear message when asset_path does not exist.
Examples: - Use when: "put the imported chair at the origin" after unreal_import_asset - Don't use when: moving something already in the level (use unreal_set_actor_transform)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as non-read-only and non-idempotent, but the description adds explicit behavioral detail: each call creates a new actor and calling twice spawns two copies. It also documents failure return format and the specific error case for a non-existent asset_path.
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?
The description is well-organized with Args, Returns, and Examples sections. Every sentence adds value, and the most important behavioral caveat about duplicate spawning is front-loaded.
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?
Covers all necessary invocation details: parameter semantics, defaults, output shape, failure behavior, source of valid inputs, and when to avoid this tool. The presence of an output schema is supportive, but the description is self-sufficient even without it.
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 description coverage is reported as 0%, so the description carries the full burden. It compensates thoroughly by explaining every parameter: asset_path, location units and default, rotation units, scale multipliers, and optional label.
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?
States a specific verb and resource: placing an existing content asset into the current level as a new actor. It also distinguishes itself from siblings by specifying where asset_path comes from and by naming what it is not for.
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?
Provides explicit 'Use when' and 'Don't use when' guidance, including the concrete alternative unreal_set_actor_transform for moving existing actors. It also tells the agent to source asset_path from unreal_list_assets, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a high-resolution screenshot of the editor viewport to a PNG file.
Unreal writes the file asynchronously, so the path is returned before the
image is guaranteed to be on disk; allow a moment before reading it. Frame
the shot first with unreal_set_viewport_camera.
Args: params (ScreenshotInput): Validated input containing: - filename (str): Absolute output path for the PNG - width (int): Width in pixels, 64-7680 (default 1920) - height (int): Height in pixels, 64-4320 (default 1080)
Returns: str: JSON confirming the request: { "requested": bool, "filename": str, # Where Unreal was told to write "resolution": [int, int], "note": str # Reminder that the write is asynchronous } On failure: "Error: "
Examples: - Use when: producing a visual check of the level after placing actors - Don't use when: you need a final production render (use Movie Render Queue via unreal_execute_python)
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the sparse annotations by disclosing the asynchronous write behavior: the path is returned before the image is on disk, so the caller must wait. It also explains the return format and the meaning of its fields, which helps the agent interpret the result correctly. No annotation is contradicted.
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?
The description is well structured: a one-sentence summary, a note on asynchronous behavior, a brief Args section, a Returns block, and an Examples section. Every block earns its place, though the Args section is somewhat redundant with the schema. It is slightly longer than strictly necessary, but remains tight and scannable.
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?
The description covers all information needed to call the tool correctly: the purpose, a prerequisite, the three modifiable parameters with defaults and ranges, the exact asynchronous caveat, and a complete return contract including failure strings. The output schema is also described. There are no gaps that would cause an agent to mis-call it.
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?
The schema already provides complete descriptions for all three parameters (filename, width, height), including an example path and bounds, so the description's Arg list largely restates this. Still, the description adds the default values and range constraints in a convenient summary, but does not introduce meaning beyond what the schema offers. With full schema coverage, a baseline of 3 is appropriate.
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 opens with a specific verb and resource: 'Capture a high-resolution screenshot of the editor viewport to a PNG file.' This clearly identifies the action and output, and distinguishes it from sibling tools like unreal_set_viewport_camera (which frames the shot) and unreal_execute_python (a general command channel). No ambiguity remains.
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 tool explicitly states when to use it ('producing a visual check of the level after placing actors') and when not to ('you need a final production render'), and names the alternative (unreal_execute_python). It also gives a prerequisite hint to frame the shot first with unreal_set_viewport_camera. This is model guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0unreal_delete_actorunreal_execute_pythonunreal_get_statusunreal_import_assetunreal_list_actorsunreal_list_assetsunreal_save_allunreal_set_actor_transformunreal_set_viewport_cameraunreal_spawn_actorunreal_take_screenshotScored across 11 tools
Each tool targets a distinct resource and action—actors, assets, the viewport, saving, or status. The only broad tool, unreal_execute_python, explicitly frames itself as an escape hatch and tells agents to prefer specific tools, so there is no real ambiguity.
Every tool follows the same `unreal_<verb>_<noun>` snake_case pattern, e.g. list_actors, spawn_actor, delete_actor, take_screenshot, save_all. This makes the tool surface highly predictable.
Eleven tools is a well-scoped size for Unreal Editor automation: core actor and asset operations, viewport control, diagnostics, and saving are all represented without excessive redundancy. Each tool earns its place.
The set covers the main actor lifecycle (list, spawn, transform, delete), asset listing/import, viewport framing, screenshots, and saving, which forms a coherent workflow. Some asset management operations like delete or rename are missing, but unreal_execute_python provides a workaround for uncovered cases.
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
