UE5-MCP-Server

Overview Schema Source Related Servers Discussions Admin

ue5_spawn_actor

Spawn an actor in an Unreal Engine 5 level by providing a static mesh asset path or an actor class, with optional location and rotation.

Instructions

Spawns an actor in the level from a static mesh asset or an actor class. Use objectPath for static meshes (e.g., '/Engine/BasicShapes/Cube.Cube') or actorClass for native classes (e.g., '/Script/Engine.DirectionalLight').

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ue5_spawn_actor"
  }
}

Input Schema

Name	Required	Description
`objectPath`	No	Asset path of the static mesh to spawn (e.g., '/Engine/BasicShapes/Cube.Cube'). Mutually exclusive with actorClass.
`actorClass`	No	Class path of the actor to spawn (e.g., '/Script/Engine.DirectionalLight'). Mutually exclusive with objectPath.
`location`	No	Spawn location { X, Y, Z }. Default: origin.
`rotation`	No	Spawn rotation { Pitch, Yaw, Roll }. Default: zero.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Jun 18, 2026

TDQS

A4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility. It only states 'spawns an actor' without disclosing side effects (e.g., affecting level state, collision handling), permissions needed, or error conditions. This is insufficient for a tool that modifies the world.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description uses two concise sentences with an efficient structure: first sentence states the core action, second sentence provides usage details. Every word adds value; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool spawns a new actor in the level, important context is missing: what is returned (actor reference?), is spawning synchronous?, what happens on failure (e.g., invalid path)? The absence of an output schema makes the description's lack of return value info a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds significant value by explaining the mutual exclusivity of objectPath and actorClass, providing example paths, and clarifying default values for location and rotation. This fully compensates for any missing schema detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'spawns an actor', specifies the resource 'in the level', and distinguishes between two modes (static mesh or actor class) with example paths. This makes it distinct from siblings like ue5_destroy_actor and ue5_spawn_actors_batch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use objectPath vs actorClass with concrete examples, guiding the agent's selection. However, it does not explicitly state when not to use this tool, such as for batch spawning, which could be inferred from sibling ue5_spawn_actors_batch but is not mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.