Allows Claude to interact with Unreal Engine 5.3 via Remote Control API to create and manipulate 3D objects, spawn actors, modify scenes, list assets, and more.
Click on "Install 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 Create a red cube at position 100, 200, 50"
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.
This repository contains a Model Context Protocol (MCP) Python server that allows Claude Desktop to interact with Unreal Engine 5.3 (via Remote Control API), creating and manipulating 3D objects based on text prompts. This integration enables Claude to build and modify 3D scenes in Unreal Engine through natural language, representing an early step toward text-to-game-generation technology.
Current Features:
use Claude Desktop text prompts to arrange assets in Unreal Engine Editor
create static meshes for assembling primitive shapes
look up Unreal project folder for assets
list actors in the current level and inspect the current editor selection
save the current level from MCP
call arbitrary Unreal Remote Control functions
read and write Unreal object properties through the Remote Control property endpoint
direct CLI with per-command --help for non-MCP agents
shared castle workflow, sample agent skill, and TLA+ use-case model
castle reset workflow and first-class castle MCP tools
Python 3.10+
Unreal Engine 5.3 with Remote Control API (plugin) enabled
Clone the repository and install in editable mode:
git clone https://github.com/runeape-sats/unreal-mcp.git
cd unreal-mcp
pip install -e .This installs the unreal-mcp-cli command and makes the unreal_mcp package importable.
if you are using Claude Desktop → File → Settings → Developer → Edit Config claude_desktop_config.json and add the following, adjusting the path to your local repository:
{
"mcpServers": {
"unreal-mcp": {
"command": "uv",
"args": ["--directory", "\\path\\to\\unreal-mcp", "run", "unreal_mcp_server.py"],
"env": {}
}
}
}If you already have other MCP servers configured (like blender-mcp), you may need to disable them to ensure they don't conflict.
Open Unreal Engine with your project and ensure the Remote Control API plugin is enabled.
Restart Claude Desktop (i.e., need a clean exit without Claude's icon in the system tray) to load the new configuration. You can verify if it's connected by asking Claude to create objects in Unreal Engine.
Related MCP server: UEMCP
unreal_mcp/ # Core package
__init__.py
server.py # MCP server — registers all tools
cli.py # Direct CLI with subcommands and --help
connection.py # HTTP connection to Unreal Remote Control API
actors.py # Actor create / modify / delete helpers
assets.py # Asset discovery and level info
remote.py # Generic Remote Control and editor helpers
utils.py # Shared constants and parsing utilities
examples/ # Example workflows (separate from core)
castle/
workflow.py # Castle build / verify / reset workflow
assets/castle-plan.json
specs/CastleConstruction.tla
tests/ # Unit tests (20 tests)
test_castle_assets.py
test_castle_workflow.py
test_unreal_cli.pyRoot-level shim modules (unreal_mcp_server.py, unreal_cli.py, etc.) re-export from unreal_mcp.* for backward compatibility.
Create primitive shapes with a variety of parameters:
Cubes, Spheres, Cylinders, Planes, Cones
Custom position, rotation, scale
Custom colors and materials
Example prompt: "Create a red cube at position 100, 200, 50"
Spawn actors from Blueprint classes:
Buildings, props, characters, etc.
Custom parameters like in Basic Object Creation
Example prompt: "Spawn a bench from the blueprint at /Game/CustomAsset/Blueprints/BP_Bench01"
Modify existing objects:
Change position, rotation, scale
Adjust colors and materials
Toggle visibility
Example prompt: "Move the cube to position 0, 0, 100 and rotate it 45 degrees"
Inspect the current level and editor selection:
List all actors in the current level, optionally with transforms
Read the actors currently selected in the editor
Select actors by label from MCP
Save the current level after a batch of changes
Example prompt: "List all actors with 'Bench' in the label and then select them"
The server now exposes a generic Remote Control escape hatch so you can reach Unreal functionality that does not yet have a dedicated MCP tool:
Call arbitrary functions on any object path
Resolve an actor label to an object path automatically
Target a component by class when reading or writing properties
Read and write properties through /remote/object/property
This is useful for driving lights, post process volumes, components, editor subsystems, and custom Blueprint-exposed APIs without adding a new Python wrapper first.
Agents that do not speak MCP can use the direct CLI instead:
unreal-mcp-cli --help lists all commands
unreal-mcp-cli <command> --help shows how to use one function
Commands route directly to the same Unreal helper modules used by the MCP server
Example commands:
unreal-mcp-cli commands
unreal-mcp-cli list-level-actors --kwargs "filter=Castle max_results=20"
unreal-mcp-cli remote-call --kwargs "actor_label=SkyLight function_name=GetActorLocation"If you have not installed the editable script yet, use .venv\Scripts\python.exe unreal_cli.py --help.
The repo now includes:
a reusable castle plan in examples/castle/assets/castle-plan.json
a sample skill in .github/skills/unreal-castle-builder/SKILL.md
a TLA+ use-case model in examples/castle/specs/CastleConstruction.tla
dedicated castle create, verify, and reset entry points in both the CLI and MCP server
The castle workflow is designed so an agent can inspect CLI help, build a castle from basic shapes, and verify the result by listing actors. The build workflow removes old castle actors with the same planned labels before placing the new ones by default. It now supports deterministic variation presets for layout, size, palette, and yaw while keeping the same required core actor set. The reset workflow deletes a castle by prefix, and the TLA+ model now covers retries, rebuilds, and variant selection as well as successful completion.
Search for and list available assets:
Filter by asset type (blueprints, meshes, materials)
Search in specific paths
Find assets matching certain terms
Example prompt: "List all bench static meshes in the project"
Here are some example prompts you can use with Claude:
Create a blue sphere at position 0, 100, 50 with scale 2, 2, 2
Create a scene with a red cube at 0,0,0, a green sphere at 100,0,0, and a blue cylinder at 0,100,0
List all blueprint assets in the /Game/CustomAsset folder
Get information about the current level
Create a cylinder and then change its color to yellow
List all actors whose label contains Bench
Show me the actors currently selected in the editor
Select actors Bench_A, Bench_B, and Bench_C
Save the current level
Set the intensity property on actor KeyLight to 5000
Call a remote function on actor SkyLight to recapture the scene
Use the CLI help for the castle workflow
Create a castle from basic shapes with prefix SkillCastle
Create a grand sandstone courtyard castle at a new placement
Verify the SkillCastle actors exist in the level
Reset the SkillCastle actors after verificationIn addition to the existing spawn, modify, delete, and asset lookup tools, the server now exposes:
list_level_actors: List actors with optional filtering and transform data
get_selected_actors: Inspect the current Unreal Editor selection
select_actors: Select actors by label
save_current_level: Save the open map
remote_call: Call any Unreal Remote Control function by object path or actor label
get_object_property: Read any Unreal object property
set_object_property: Write any Unreal object property
create_basic_castle: Build the shared primitive castle workflow directly from MCP
verify_basic_castle: Verify the expected castle actor set by prefix
reset_basic_castle: Delete castle actors by prefix or strict plan labels
The castle create entry point accepts layout, size, palette, origin, and yaw so agents can generate deliberate castle variants while the verification step still checks for the same required labels.
For complex remote_call or property writes, prefer JSON-shaped arguments so nested parameter structs survive parsing cleanly.
Install the project in editable mode inside your virtual environment to get the unreal-mcp-cli command:
.venv\Scripts\python.exe -m pip install -e .
unreal-mcp-cli --helpUseful command patterns:
unreal-mcp-cli create-static-mesh-actor --help
unreal-mcp-cli create-basic-castle --prefix SkillCastle --layout courtyard --size grand --palette sandstone
unreal-mcp-cli create-basic-castle --prefix Bastion01 --origin 6000,1200,0 --yaw 45 --palette obsidian
unreal-mcp-cli list-level-actors --kwargs "filter=SkillCastle max_results=40"
unreal-mcp-cli verify-basic-castle --prefix SkillCastle
unreal-mcp-cli reset-basic-castle --prefix SkillCastle --strict-plancreate-basic-castle replaces matching old castle actors by default. Use --keep-existing only if you explicitly want overlapping duplicates.
Named presets provide controlled variation: --layout changes the footprint, --size changes the overall scale, --palette changes default colors, and --origin or --yaw change placement/orientation.
Run the automated tests with:
.venv\Scripts\python.exe -m unittest discover -s tests -vThese tests cover the CLI surface, the shared castle plan, the TLA+ actor set, and the sample skill wiring.
Make sure Unreal Engine is running before starting the MCP server
Ensure the Remote Control API plugin is enabled in Unreal Engine
Check if another process is using port 30010
Verify your firewall is not blocking the connection
Check the output log in Unreal Engine for any errors
Make sure objects are not being created too far from the origin (0,0,0)
Try simplifying your requests to isolate issues
The server logs detailed information to the console. If you're having issues, check the logs for error messages and tracebacks.
To run the server in development mode:
pip install mcp[cli]
mcp dev unreal_mcp_server.pyContributions are welcome! This is an integration between Claude and Unreal Engine, and there's much that can be improved:
Better natural language processing for scene descriptions
More complex object creation capabilities
Supporting more Unreal Engine features
Improved error handling and feedback
Create a sample castle workflow from primitive shapes.
Parameters:
kwargs: Optional key=value pairs or JSON object Supported parameters:
prefix: Actor label prefix, default Castle
origin: x,y,z base location
stone_color: r,g,b or r,g,b,a color for stone elements
roof_color: r,g,b or r,g,b,a color for roof elements
layout: classic, courtyard, bastion, or longhall
size: compact, standard, or grand
palette: granite, sandstone, moss, or obsidian
yaw: rotate the layout around the origin in degrees
replace_existing: true/false, default true
dry_run: true/false, default false
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions parameters like 'replace_existing' and 'dry_run' but does not explain their implications (e.g., whether the tool overwrites existing actors or requires specific permissions). The behavioral impact is unclear.
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 a single block listing parameters. It efficiently states the purpose but lacks clear structuring (e.g., bullet points or sections). It is adequate but not optimally concise.
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?
Despite having an output schema (not shown), the description is incomplete. It doesn't mention prerequisites, level context, or how the tool fits with siblings like 'reset_basic_castle'. The parameter details are helpful but insufficient for full context.
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 0% (only 'kwargs' with no description), so the description compensates by listing supported sub-parameters (prefix, origin, stone_color, etc.). However, it does not specify the exact format for 'kwargs' (e.g., JSON object or key=value pairs), which limits clarity.
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's action: 'Create a sample castle workflow from primitive shapes.' This is a specific verb and resource, distinguishing it from siblings like 'reset_basic_castle' or 'verify_basic_castle'.
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 no guidance on when to use this tool versus alternatives like 'spawn_actor_from_blueprint' or 'modify_actor'. No explicit usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new static mesh actor in the Unreal Engine level using a simpler approach.
Parameters:
kwargs: String containing parameters as key=value pairs or JSON object Example: "actor_label=Cube mesh_type=CUBE location=0,0,0"
Supported parameters:
actor_label/name: Name for the actor
mesh_type: One of CUBE, SPHERE, CYLINDER, PLANE, CONE
location: x,y,z location coordinates
rotation: pitch,yaw,roll rotation in degrees
scale: x,y,z scale factors. 1 means same scale (100%)
color: r,g,b color values (0.0-1.0)
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden; it only states creation and lists parameters but does not disclose side effects, authorization needs, error behavior, or return value.
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 short, front-loaded with the purpose, and efficiently uses bullet-style parameter details without superfluous 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 input parameters adequately but omits output details (despite output schema existing), prerequisites like open level, or comparison with sibling tools, leaving gaps for a tool with minimal annotations.
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 offers no parameter descriptions (0% coverage). The description compensates fully by explaining the kwargs format, listing supported parameters with examples and allowed values (e.g., mesh types, coordinate formats).
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 verb 'create' and resource 'static mesh actor' in Unreal Engine level, and hints at a simpler approach but does not explicitly differentiate from sibling tools like spawn_static_mesh.
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 mentions a 'simpler approach' but provides no explicit guidance on when to use this tool versus alternatives, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a specific actor from the Unreal Engine level.
Parameters:
actor_label: The label/name of the actor to delete
| Name | Required | Description | Default |
|---|---|---|---|
| actor_label | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'delete' but does not describe side effects (e.g., what happens to attached components, undo capabilities, permission requirements). For a destructive action, this is insufficient.
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 brief with two sentences plus a parameter block. However, the parameter listing could be integrated more concisely, and the structure is acceptable but not optimally 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?
The tool has one parameter and no annotations, but the description omits crucial context: return value (output schema exists but is not explained), error states, and safety considerations. Given the destructive nature, this is a notable gap.
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 restates the parameter 'actor_label' with a brief explanation, but adds no new semantic meaning beyond the schema's title. With 0% schema description coverage, the description fails to compensate (e.g., no mention of format, case sensitivity, or how to obtain a valid 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?
The description clearly states the action ('delete') and the resource ('a specific actor from the Unreal Engine level'). It is distinct from sibling tools like 'modify_actor' or 'select_actors'.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., 'spawn_actor_from_blueprint' or 'modify_actor'). There are no preconditions, no warnings about irreversibility, and no scenarios where deletion is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific actor in the Unreal Engine level.
Parameters:
actor_label: The label/name of the actor to get information about
| Name | Required | Description | Default |
|---|---|---|---|
| actor_label | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It does not disclose whether the tool is read-only, if it has side effects, or what 'detailed information' entails. Lacks behavioral context.
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?
Very concise, only two sentences and a parameter description. No unnecessary information; every part adds value.
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?
Output schema exists, so return values are covered. However, description lacks context on error handling, prerequisites (actor must exist), or what properties are included. Adequate but not comprehensive.
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 0%, but description adds meaning by explaining actor_label refers to the label/name of the actor, which is not in the schema. Provides sufficient guidance for parameter use.
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?
Clearly states the tool gets detailed information about a specific actor in Unreal Engine level, with a specific verb and resource. Distinguishes from sibling tools like get_level_info or get_selected_actors.
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?
No explicit guidance on when to use vs alternatives. Implicitly suggests use when actor label is known, but no when-not-to-use or mentions of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the current Unreal Engine level and update spatial context.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It mentions 'update spatial context' implying a write operation, but does not explain what is updated or whether changes are reversible. This leaves critical behavioral gaps.
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 a single sentence, making it concise. However, the 'and update spatial context' clause feels tacked on and could be separated for clarity. Overall efficient but could be more structured.
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 tool has no parameters and an output schema, so structural completeness is adequate. However, the ambiguity about side effects and lack of usage context leaves gaps in understanding the tool's full behavior, making it only minimally complete.
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?
There are no parameters, so schema coverage is trivially 100%. The description does not need to add parameter details. Baseline 4 is appropriate as the description provides no contradictory or unnecessary parameter info.
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 'Get information about the current Unreal Engine level' which gives a clear verb and resource, but adds 'and update spatial context' which introduces ambiguity about whether the tool has write side effects. This blurs the purpose and fails to differentiate from sibling 'get_spatial_context'.
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?
No guidance is provided on when to use this tool vs alternatives like 'get_spatial_context' or 'list_level_actors'. There is no mention of prerequisites, exclusions, or contrasting cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read any Unreal object property through the Remote Control property endpoint.
Parameters:
kwargs: key=value pairs or JSON object Supported parameters:
object_path: Direct Unreal object path
actor_label: Actor label to resolve into an object path
component_class: Optional component class to resolve from the actor
property_name: Unreal property name to read
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not explicitly state that the tool is read-only, has no side effects, or describe error behavior. The word 'read' suggests safety but is not definitive.
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 concise, front-loads the main action, and uses a bulleted list for parameters. Every sentence adds value 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?
The tool has an output schema, so explaining return values is unnecessary. The description adequately explains the parameters. However, it does not mention prerequisites like a loaded level or object existence, but given the simplicity, it is mostly complete.
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 only defines 'kwargs' as a string with no description, resulting in 0% schema coverage. The description compensates by listing the supported parameters (object_path, actor_label, component_class, property_name) and explaining that kwargs accepts key=value pairs or a JSON object.
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 verb 'read' and the resource 'Unreal object property'. The tool distinguishes from its sibling 'set_object_property' which is the write counterpart.
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 implies usage for reading properties but does not explicitly state when to use this tool versus alternatives like 'remote_call' or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the actors currently selected in the Unreal Editor.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description clearly implies a read-only operation with no side effects ('Get'). It conveys the basic behavioral trait of returning the current selection. Since an output schema exists, no need to detail return values. A minor gap is no explicit statement about being non-destructive, but it's clear enough.
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?
Single sentence, no unnecessary words. Perfectly concise and front-loaded with the key action and resource.
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 simple getter with zero parameters and an output schema, the description is completely adequate. It tells the agent exactly what the tool does without requiring further elaboration. No additional context is needed.
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 tool has zero parameters, and the schema description coverage is 100% trivially. Baseline score of 3 is appropriate because no parameter details are needed and the description adds no additional semantics.
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 verb 'Get' and the resource 'actors currently selected in the Unreal Editor'. It effectively distinguishes from siblings like 'select_actors' (which selects) and 'get_actor_info' (which gets info on a specific actor) by specifying the selection scope.
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?
No guidance on when to use this tool versus alternatives such as 'get_actor_info', 'list_level_actors', or 'select_actors'. The description does not mention context, exclusions, or prerequisites, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current spatial context of all actors as a JSON string.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return type (JSON string) and scope (all actors) but does not describe side effects, permissions, or performance characteristics.
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 a single, clear sentence with no wasted words. It is perfectly concise for a tool with no parameters.
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 is adequate for a simple getter but lacks detail on what 'spatial context' includes (e.g., position, rotation, scale). The output schema may provide this, but the description could be more descriptive.
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?
With zero parameters and 100% schema coverage, the description has nothing to add about parameters. Baseline score of 4 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 clearly states it returns the current spatial context of all actors as a JSON string. This distinguishes it from sibling tools like reset_spatial_context, which modifies spatial context.
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 implies usage for reading spatial data but does not explicitly provide when to use or when to avoid. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available assets of a specific type in the Unreal Engine project.
Parameters:
kwargs: String containing parameters as key=value pairs or JSON object Example: "asset_type=StaticMesh search_path=/Game/AssetName search_term=House"
Supported parameters:
asset_type: Type of assets to list (BlueprintClass, StaticMesh, Material, etc.)
search_path: Optional path to search for assets (default: /Game)
search_term: Optional term to filter results
max_results: Maximum number of results to return (default: 20)
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully explain behavior. It only states it lists assets without discussing side effects, performance, or error states. Basic read operation assumed but not elaborated.
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 a clear purpose statement, example, and parameter list. Slightly verbose with repeat headers, but each sentence adds value.
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 main sub-parameters and defaults, but lacks mention of output structure (though output schema exists), error handling, or limits beyond max_results. Adequate but not exhaustive.
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 has only a single 'kwargs' string parameter with no description. The tool description adds extensive meaning: it explains the format (key=value or JSON), lists four supported sub-parameters with examples, and covers default values.
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 action is to list available assets, the resource is assets in the Unreal Engine project, and it requires a specific type. The supported parameters are listed, providing full specificity.
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?
No guidance on when to use this tool versus alternatives like search_assets_recursively. It implies asset_type is needed but doesn't specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List actors in the current level.
Parameters:
kwargs: Optional key=value pairs or JSON object Supported parameters:
filter: Case-insensitive label/path substring filter
include_transforms: true/false, default true
max_results: Maximum actors to return, default 100
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description discloses parameter defaults (max_results=100, include_transforms=true) and implies a read-only list operation. However, it does not explicitly state that the tool is non-destructive or safe.
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?
Description is concise with a clear one-line purpose followed by parameter details. No unnecessary words, though the parameter format could be slightly more structured.
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?
Output schema exists, so missing return value explanation is acceptable. However, the description lacks examples or edge-case handling (e.g., what happens if filter matches nothing). Adequate for a simple tool but not fully complete.
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 0% (only 'kwargs' with no description). The description compensates fully by detailing supported parameters (filter, include_transforms, max_results) with defaults, adding critical meaning beyond the schema.
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?
Description clearly states 'List actors in the current level' with a specific verb and resource. It distinguishes from sibling tools like 'get_selected_actors' (selected actors) and 'get_level_info' (level info), making its purpose unambiguous.
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?
No explicit guidance on when to use this tool versus alternatives like 'get_selected_actors' or 'search_assets_recursively'. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify an existing actor in the Unreal Engine level.
Parameters:
kwargs: String containing parameters as key=value pairs or JSON object Example: "actor_label=Cube location=100,200,50 rotation=0,45,0"
Supported parameters:
actor_label: Label/name of the actor to modify (required)
location: x,y,z location coordinates
rotation: pitch,yaw,roll rotation in degrees
scale: x,y,z scale factors
visible: true/false to set visibility
color: r,g,b color values (0.0-1.0)
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It does not mention side effects, permission requirements, return values, or error behavior. The output schema exists but is not referenced.
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 reasonably concise but could be more structured. It includes an example and parameter list, which is helpful, but there is some redundancy (e.g., 'Parameters:' line). Overall adequate.
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 essential usage (how to supply parameters) but omits behavioral context like what happens on failure, whether changes are undoable, or output format. With an output schema available, the lack of return info is partially mitigated, but not fully.
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 has only a string kwargs parameter with 0% description coverage. The description compensates with a detailed example and list of supported parameters (actor_label, location, rotation, etc.), adding meaning beyond the schema.
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 'Modify an existing actor in the Unreal Engine level,' which is a specific verb+resource. The sibling tools include delete, get, and spawn operations, making this tool's purpose distinct.
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?
No guidance on when to use this tool versus alternatives like set_object_property or spawn_actor_from_blueprint. The description lacks context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call any Unreal Remote Control function.
Parameters:
kwargs: key=value pairs or JSON object Supported parameters:
object_path: Direct Unreal object path
actor_label: Actor label to resolve into an object path
component_class: Optional component class to resolve from the actor
function_name: Unreal function to call
parameters: JSON object of function parameters
generate_transaction: true/false, default true
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'generate_transaction' which hints at transactional behavior, but it does not state safety (read-only vs. destructive), authentication needs, error handling, or side effects. The description is insufficient for predicting tool behavior.
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 relatively short and front-loaded with the main purpose. The parameter list is structured with bullet points, making key information easy to scan. Every sentence serves a purpose, though the list could be slightly more compact.
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 presence of an output schema (so return values need not be explained), the description covers the core function and parameter structure. However, it lacks guidance on error behavior, authentication, and when to use this tool over siblings. For a generic gateway tool, more context about fallback usage and side effects would improve completeness.
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 has only one untyped 'kwargs' string with 0% description coverage. The description compensates by listing supported sub-parameters (object_path, actor_label, etc.) and their meanings, adding significant semantic information beyond the schema. However, it could be clearer on format (e.g., exact JSON structure).
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 verb 'Call' and resource 'any Unreal Remote Control function', making the purpose clear. However, it does not differentiate from more specific sibling tools like set_object_property or modify_actor, which could cause confusion about when to use this generic tool vs. specialized ones.
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?
No explicit guidance on when to use this tool versus alternatives. The description lists parameters but does not indicate prerequisites, appropriate contexts, or exclusions. Sibling tools cover specific operations (e.g., create_static_mesh_actor), so usage guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a castle by prefix.
Parameters:
kwargs: Optional key=value pairs or JSON object Supported parameters:
prefix: Actor label prefix, default Castle
strict_plan: true/false, default false
dry_run: true/false, default false
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructive nature ('delete'), but lacks details on side effects, permissions, or irreversibility. Parameters like 'dry_run' hint at behavior but are not explained in terms of impact.
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?
Description is short and structured with a list of parameters, but the 'kwargs' parameter in schema is not fully detailed. No extraneous text.
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?
Despite having an output schema (not provided), the description is minimal. It does not mention return values, error conditions, or prerequisites, leaving gaps for a deletion tool.
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 0%, and the description adds meaning for parameters (prefix, strict_plan, dry_run) with defaults and purposes, compensating for the sparse schema.
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?
Description clearly states 'Delete a castle by prefix', with a specific verb and resource. It distinguishes from sibling 'delete_actor' by specifying 'castle' and 'prefix', but does not explicitly differentiate from other castle-related 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?
No guidance on when to use this tool vs siblings like delete_actor, verify_basic_castle, or create_basic_castle. No mention of preconditions or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset the spatial context, clearing all tracked actors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavioral trait: clearing all tracked actors. However, with no annotations, it lacks details on whether this is destructive, reversible, or requires permissions. Adequate but minimal.
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?
Single sentence, direct, no filler. Every word adds value.
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 zero parameters and presence of an output schema, the description covers the core function. However, it could mention return behavior or confirm whether actors are destroyed or untracked.
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?
No parameters exist, so schema coverage is 100% by default. The description adds no parameter info, but none is needed. Baseline 4 for zero parameters.
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 resets the spatial context by clearing all tracked actors, with a specific verb and resource. It distinguishes from siblings like get_spatial_context (retrieval) and other 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?
No guidance on when to use this tool versus alternatives such as reset_basic_castle or manual deletion. The description provides no context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the currently open Unreal level.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action, without disclosing behavioral traits such as whether it overwrites the existing file, requires permissions, or handles unsaved changes. Minimal disclosure.
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?
A single sentence that is front-loaded and contains no extraneous words. It efficiently communicates the tool's purpose.
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 low complexity (0 params, simple action) and the existence of an output schema, the description is sufficient for the core action. It could mention file path or confirmation requirements, but overall it provides enough context for invocation.
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 tool has zero parameters, and schema coverage is 100% (trivially). The description does not need to add parameter info, and the baseline for 0 parameters is 4. The description is adequate.
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 'Save the currently open Unreal level' uses a specific verb 'save' and explicitly names the resource 'currently open Unreal level', clearly distinguishing it from sibling tools like create, delete, and get.
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 implies when to use (when you want to save the level), but provides no explicit guidance on when not to use or alternatives. No exclusions or context about prerequisites like needing unsaved changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for assets recursively in all common subdirectories.
Parameters:
base_path: The base path to search in (e.g., '/Game/KyotoAlley')
asset_type: Optional type of assets to filter by
search_term: Optional search term to filter results
max_results: Maximum number of results (default: 50)
| Name | Required | Description | Default |
|---|---|---|---|
| base_path | Yes | ||
| asset_type | No | ||
| search_term | No | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions recursive search but does not clarify performance implications, error behavior, authorization needs, or what 'common subdirectories' means, leaving significant ambiguity.
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 very concise: one purpose sentence followed by a clear parameter list. No extraneous words, and the structure is easy to parse.
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 presence of an output schema, return values are covered. The description explains the parameters and the recursive behavior, but the term 'common subdirectories' needs clarification. Overall, it's fairly complete for a search tool.
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?
With 0% schema coverage, the description adds meaning by listing and briefly explaining each parameter (base_path, asset_type, search_term, max_results with default). While basic, it compensates for the lack of schema descriptions.
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 verb 'search', the resource 'assets', and the recursive nature in 'all common subdirectories'. It distinguishes from siblings like 'list_available_assets' which likely does not recurse.
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 does not explicitly state when to use or not use this tool, nor mention alternatives. The term 'common subdirectories' is ambiguous and provides no guidance on scope or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select one or more actors in the Unreal Editor.
Parameters:
kwargs: key=value pairs or JSON object Supported parameters:
actor_labels: Comma-separated list or JSON array of actor labels
replace_selection: true/false, default true
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions replace_selection parameter indicating behavior, but no annotations exist. It lacks disclosure of side effects, error handling, or whether selection is cleared before adding. Some behavioral transparency is provided, but not comprehensive.
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 relatively concise, but duplicates parameter documentation within the description field rather than using a separate structure. Could be more streamlined.
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?
Despite having an output schema, the description does not mention return value or errors. Provides essential parameter info but lacks details on edge cases, outcomes when actors not found, or interaction with other tools.
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 has only one string parameter 'kwargs' with no description. The description adds meaning by listing supported sub-parameters (actor_labels, replace_selection) and format hints, but does not fully specify formats (e.g., exact JSON syntax). Schema coverage is 0%, so description partially compensates.
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 selects one or more actors in the Unreal Editor, which is a specific verb+resource. It distinguishes from siblings like delete_actor or modify_actor.
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?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write any Unreal object property through the Remote Control property endpoint.
Parameters:
kwargs: key=value pairs or JSON object Supported parameters:
object_path: Direct Unreal object path
actor_label: Actor label to resolve into an object path
component_class: Optional component class to resolve from the actor
property_name: Unreal property name to write
property_value: Value to assign, preferably via JSON for structs
generate_transaction: true/false, default true
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions using the Remote Control endpoint but lacks critical behavioral details such as side effects, error handling, permissions, or reversibility. Since no annotations are provided, the description bears full responsibility and falls short.
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 front-loaded with the main purpose and then lists parameters in a structured way, but it is somewhat verbose and could be more concise by grouping or simplifying the parameter list.
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 complexity of a single parameter wrapping many sub-parameters, the description covers the main aspects adequately. The existence of an output schema reduces the need to explain return values, but some usage context (e.g., required fields, validation) 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 only defines 'kwargs' as a string with 0% description coverage, but the description compensates by listing supported sub-parameters (object_path, actor_label, etc.) with brief explanations, adding significant semantic value.
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 verb 'Write' and resource 'Unreal object property', distinguishing it from sibling tools like get_object_property (read) and remote_call (function invocation).
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 implies usage for writing properties but does not explicitly state when to use this tool versus alternatives like get_object_property or modify_actor, nor does it provide context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Spawn a level actor based on an Unreal Blueprint class.
Parameters:
kwargs: String containing parameters as key=value pairs or JSON object Example: "actor_class=/Game/AssetName/Blueprints/BP_House0.BP_House0_C location=100,100,0 name=MyHouse"
Supported parameters:
actor_class: (required) Path to the blueprint class
actor_label/name: Name for the actor
location: x,y,z location coordinates
rotation: pitch,yaw,roll rotation in degrees
scale: x,y,z scale factors
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description carries full burden. It does not disclose behavioral traits such as side effects (adding to level), permissions, or rate limits. It only states it spawns an actor, missing key context for a mutation tool.
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 concise, front-loaded with purpose, and uses a structured list for parameters. Every sentence adds value with no 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?
Given the tool's complexity (1 parameter encoding multiple sub-params) and the presence of an output schema, the description covers all necessary invocation details (parameters and format). No missing critical context.
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 0% (only string type). The description fully compensates by listing all supported sub-parameters (actor_class, location, etc.), format, and an example, providing essential meaning beyond the empty schema.
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 it spawns a level actor from an Unreal Blueprint class. The verb 'spawn' plus resource 'actor from Blueprint' is specific and distinguishes it from siblings like spawn_static_mesh or create_static_mesh_actor.
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 implies usage for Blueprint-based actors but does not explicitly indicate when to use this tool versus alternatives like spawn_static_mesh. No when-not-to-use or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Spawn a static mesh actor using an existing static mesh asset from the content browser.
Parameters:
kwargs: String containing parameters as key=value pairs or JSON object Example: "static_mesh=/Game/AssetName/Meshes/Bench01 location=100,100,0 name=MyBench"
Supported parameters:
static_mesh: (required) Path to the static mesh asset
actor_label/name: Name for the actor
location: x,y,z location coordinates
rotation: pitch,yaw,roll rotation in degrees
scale: x,y,z scale factors
material_override: Path to material to use
color: r,g,b color values (0.0-1.0)
| Name | Required | Description | Default |
|---|---|---|---|
| kwargs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions that the tool uses an existing asset and lists parameters, but it does not describe side effects, permissions required, or what happens on success (e.g., returns an actor reference). The output schema exists but is not shown, so the agent lacks behavioral context.
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 moderately sized, including essential details like the required static_mesh parameter and optional parameters. It could be more concise by removing redundant formatting; however, it is structured logically with an example and parameter list.
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?
Though an output schema exists (alleviating the need to explain return values), the description lacks behavioral transparency and usage guidelines. For a spawning tool, critical context about success outcomes and permissions is missing, making it incomplete for an AI agent.
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 has 0% parameter description coverage, so the description fully compensates by listing all supported keys (e.g., static_mesh, location, rotation) and showing an example format. This adds significant meaning beyond the schema's minimal definition.
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?
Description clearly states the tool spawns a static mesh actor from an existing asset, specifying the verb and resource. However, it does not distinguish from the sibling tool 'create_static_mesh_actor', which may have overlapping functionality.
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 a list of supported parameters and an example of kwargs format, which helps in usage. However, it does not specify when to use this tool over alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that a castle built from the shared plan exists in the current level.
Parameters:
prefix: Actor label prefix, default Castle
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No | Castle |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should fully disclose behavior. Indicates a read-like verification but does not specify side effects, error handling, or what constitutes a 'castle built from the shared plan.'
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?
Highly concise with two sentences and a parameter list. No fluff, but the parameter list is redundant with the input schema. Slightly under-specified.
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 simple tool with one parameter and an output schema (not shown), the description is minimal but covers basic intent. Lacks explanation of verification logic and return value, but output schema may compensate.
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 0%, so description must add meaning for the single parameter. Only says 'Actor label prefix, default Castle' which barely extends the schema. Does not explain how prefix is used in verification.
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?
Clearly states the tool verifies existence of a castle built from a shared plan in the current level. Distinguishes from sibling tools like create_basic_castle and get_actor_info.
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?
No guidance on when to use this tool versus alternatives like get_actor_info or get_level_info. No mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Some tools overlap in purpose, e.g., create_static_mesh_actor vs spawn_static_mesh both create static mesh actors, and list_available_assets vs search_assets_recursively both list assets. Also, get_actor_info vs get_object_property and modify_actor vs set_object_property share similar scopes. Descriptions help but boundaries are fuzzy.
Most tools follow a verb_noun pattern with snake_case, e.g., create_static_mesh_actor, list_level_actors. However, there are minor inconsistencies like create vs spawn for similar actions, and remote_call uses 'call' instead of a clearer noun. Overall, the pattern is readable and mostly consistent.
With 21 tools, the server covers a broad range of Unreal operations but includes several castle-specific tools (3) that seem niche. The count is high but still manageable for integration. Slight bloat due to overlapping tools.
The tool set covers actor creation/modification/deletion, asset listing, and spatial context, but lacks asset deletion, blueprint editing (beyond spawning), level management (e.g., new level), and undo support. The presence of general-purpose remote_call and set_object_property partially compensates but indicates missing high-level functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloud Blender for AI agents: scenes, assets, renders, MP4, STL, GLB — over hosted remote MCP.
Deploy sims to any screen. Control your displays with Claude.
Deploy sims to any screen. Control your displays with Claude.
Connect Claude AI to UluP Spaces via MCP — create projects, nodes, and tasks with OAuth 2.0.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/runeape-sats/unreal-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
