Skip to main content
Glama

create_camera

Spawn a new camera actor in the Unreal Editor world (not PIE) at an optional location and rotation, then use its returned actor name to move or re-aim it later.

Instructions

Spawn a new ACameraActor in the editor world (never in PIE) at an optional location and rotation, with camera_name as its outliner label. Labels need not be unique, so address the camera later by the returned actor_name. Each location axis must be within +-100000, otherwise an error. The level is marked dirty, not saved. location_set, rotation_set and label_set compare what the spawned actor reports with the request. Move or re-aim it with set_camera_transform; spawn_actor places a CameraActor in PIE too; add_camera_component puts a camera on an existing actor.

Returns: { camera_name: string, camera_created: bool, actor_name: string, location_set: bool, rotation_set: bool, label_set: bool, actual_label: string, actual_location: [number, number, number] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
locationNoOptional [X, Y, Z] world location for the new camera (defaults to origin)
rotationNoPREFERRED: the OBJECT {"roll":R,"pitch":P,"yaw":Y} (any subset, absent axes are 0). The ARRAY form below is [pitch, yaw, roll] -- its index 2 is ROLL, NOT yaw, which once put a PlayerStart on its side. Optional [Pitch, Yaw, Roll] world rotation for the new camera (defaults to zero)
camera_nameYesName to assign to the new camera actor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety (readOnly=false, destructive=false, non-idempotent). The description adds real value beyond them: the +-100000 axis constraint with error behavior, that the level is marked dirty but not saved, and that labels need not be unique so the returned actor_name is the durable handle. It doesn't describe auth/permission requirements, keeping it short of a 5.

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-loads what is spawned, then constraints, then the comparison block, then return fields. Dense but every clause carries information; the long run of return keys is the weakest part but still useful context for a tool with no output schema.

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?

For a 3-param mutation with no output schema, it covers creation scope, coordinate limits, dirty-not-saved side effect, label semantics, and sibling routing. The inline 'Returns' contract compensates for the absent output schema. Minor gap: no mention of undo/transactability or permission requirements.

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 coverage is 100% and the rotation schema already warns about the [pitch, yaw, roll] ordering trap, so the description earns only the baseline. It does restate the label semantics ('camera_name as its outliner label') and the non-uniqueness, which adds a small amount beyond the schema's bare 'Name to assign'.

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 a new ACameraActor in the editor world'), scopes it (never in PIE), and explicitly distinguishes from siblings set_camera_transform, spawn_actor, and add_camera_component. An agent can tell it apart without opening a schema.

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

Usage Guidelines5/5

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

Names alternatives explicitly and the conditions that select them: set_camera_transform for moving/re-aiming, spawn_actor for PIE, add_camera_component for attaching to existing actors. Also states the when-not (never in PIE) and what to do instead.

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