Skip to main content
Glama

place_player_start

Place a player start in the Unreal Editor world by spawning an APlayerStart actor at a location; add optional rotation and player-start tag, and confirm the actor's read-back transform.

Instructions

Spawn an APlayerStart actor in the editor world at the given location with optional rotation + player-start tag. Location AND rotation are RE-READ from the actor after writing them, so a mismatch is visible instead of echoed back.

Returns: { actor_name, location: [x,y,z] (RE-READ from the actor), rotation: {roll,pitch,yaw} (RE-READ from the actor, axes NAMED), is_spatially_loaded: bool, location_matches_request: bool, rotation_matches_request: bool, player_start_tag, spawned: bool, already_existed: bool, requested: { location, rotation, player_start_tag, name } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional label for the new actor. Defaults to "PlayerStart_N".
locationNo[X, Y, Z] world location for the spawn point.
rotationNoOptional world rotation. TWO forms: the unambiguous OBJECT form {"roll":R,"pitch":P,"yaw":Y} (RECOMMENDED) or the ambiguous ARRAY form [Pitch, Yaw, Roll] -- note the array order, index 2 is ROLL, not yaw. Default identity.
player_start_tagNoOptional FName for the PlayerStart.Tag UPROPERTY (e.g. "Red", "Spectator", "DM"). Used by AGameModeBase to filter start points by team.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish the write-but-non-destructive, non-idempotent profile. The description adds genuinely useful behavior beyond that: it discloses that location and rotation are RE-READ from the actor after writing so mismatches surface rather than being echoed, and the returns block implies reuse via the already_existed flag. It does not cover permissions or failure behavior.

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

Conciseness4/5

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

Front-loaded with the spawn action and scope in the first sentence, followed by the read-back rationale and a structured returns block. Every part earns its place, though the trailing Returns enumeration is long and slightly overwhelms the prose.

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

Completeness4/5

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

With no output schema, the description carries the return-value burden and does so thoroughly, enumerating actor_name, re-read location/rotation, match flags, and requested values. Combined with annotations covering the safety profile, the definition is nearly complete; only error/edge-case behavior (e.g., what 'already_existed' means operationally) is left implicit.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters in detail (including the rotation object vs array ambiguity and the tag's team-filtering role). The description only echoes the optionality of rotation and tag, adding little beyond structured data. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Spawn an APlayerStart actor in the editor world') plus the configurable attributes (location, rotation, player-start tag). An agent can distinguish this from the generic spawn_actor and from register_spawn_point without opening the schema.

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

Usage Guidelines3/5

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

The tool's purpose is clear enough that usage is implied, but there is no explicit when-to-use guidance or routing to alternatives like spawn_actor or register_spawn_point, both of which live in the sibling list. No exclusions or prerequisites are stated.

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

Deploy Server

Other Tools