Skip to main content
Glama

add_spring_arm

Destructive

Attach a spring arm (camera boom) to an actor in the Unreal editor by name or label, configuring an existing arm or creating a new instance component. Use before adding a camera component.

Instructions

Add a USpringArmComponent (camera boom) to an actor placed in the editor world, found by name or label; if the actor already has a spring arm, that first one is configured instead, whatever its name, overwriting only the fields you pass. A new arm becomes an instance component attached to the root. One undo step; the level is marked dirty, not saved. Negative lengths, sizes and speeds clamp to 0; an unknown probe_channel is an error and nothing is created or written. Attach a camera with add_camera_component (parent_component = the returned component_name); for a Blueprint asset use add_component_to_blueprint.

Returns: { actor_name, component_name, already_existed, applied_count, target_arm_length, socket_offset: [x,y,z], target_offset: [x,y,z], probe_size, probe_channel, b_do_collision_test, b_use_pawn_control_rotation, b_inherit_pitch, b_inherit_yaw, b_inherit_roll, b_enable_camera_lag, b_enable_camera_rotation_lag, camera_lag_speed, camera_rotation_lag_speed }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actor_nameYesName or label of the target actor in the editor world.
probe_sizeNoOptional float. Collision probe radius.
b_inherit_yawNoOptional bool. Inherit yaw from parent.
probe_channelNoOptional string name of ECollisionChannel (e.g. "Camera", "Visibility"). Default "Camera".
socket_offsetNoOptional [X, Y, Z] relative offset applied at the spring-arm tip.
target_offsetNoOptional [X, Y, Z] world-space offset applied at the start of the spring.
b_inherit_rollNoOptional bool. Inherit roll from parent.
component_nameNoOptional name for a new component (defaults to "SpringArm"); a name another object of the actor already has gets a unique variant, returned in component_name. Ignored when the actor already has a spring arm, which is configured whatever its name.
b_inherit_pitchNoOptional bool. Inherit pitch from parent.
camera_lag_speedNoOptional float. Positional lag speed (units/sec).
target_arm_lengthNoOptional float. Natural length of the spring arm (uu). Default 300.
b_do_collision_testNoOptional bool. Enable camera collision probe.
b_enable_camera_lagNoOptional bool. Enable positional lag.
camera_rotation_lag_speedNoOptional float. Rotational lag speed (deg/sec).
b_use_pawn_control_rotationNoOptional bool. Use the parent pawn's view rotation.
b_enable_camera_rotation_lagNoOptional bool. Enable rotational lag.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.2
    • changedInput schema / properties / component_name / description
      Previous value: -"Optional name for a new component (defaults to \"SpringArm\"); use a name no other component of the actor has. Ignored when the actor already has a spring arm, which is configured whatever its name."New value: +"Optional name for a new component (defaults to \"SpringArm\"); a name another object of the actor already has gets a unique variant, returned in component_name. Ignored when the actor already has a spring arm, which is configured whatever its name."
  2. Changed1 schema field changedv1.2.0
    • changedInput schema / properties / component_name / description
      Previous value: -"Optional name for the new component (defaults to \"SpringArm\"). If a component with this name already exists, only the provided fields are updated."New value: +"Optional name for a new component (defaults to \"SpringArm\"); use a name no other component of the actor has. Ignored when the actor already has a spring arm, which is configured whatever its name."
  3. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing undo behavior ('one undo step'), dirty-state semantics ('the level is marked dirty, not saved'), clamping rules for negative values, error behavior for an unknown probe_channel ('nothing is created or written'), and the overwrite-only-passed-fields merge rule. It does not contradict the destructiveHint=true annotation. It could mention whether the existing arm's other settings are preserved in more detail, but disclosure is strong.

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?

Dense but front-loaded: the core action and lookup come first, then behavior notes, then routing. The trailing return-value enumeration duplicates what a caller could infer and is somewhat lengthy, but overall each clause carries information.

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 16-parameter mutation tool with no output schema, the description covers creation-vs-reuse semantics, undo/dirty behavior, error behavior, and alternative tools. The return field list is included even without an output schema, which compensates. Minor gap: no mention of required permissions or whether the actor must be movable/root-attachable.

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%, so the schema already documents all 16 parameters with types and defaults. The description adds a few semantic clarifications (clamping, probe_channel error handling, component_name collision renaming) but does not enumerate the parameter meaning itself, so the schema carries the load. 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+resource ('Add a USpringArmComponent (camera boom) to an actor') and specifies the lookup mechanism (found by name or label). It also distinguishes itself from siblings by naming add_camera_component and add_component_to_blueprint as the relevant alternatives.

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?

Explicitly states when the tool applies (editor world actor, found by name/label), what happens if a spring arm already exists (first one is configured instead), and routes the agent to the correct alternatives: add_camera_component for attaching a camera, add_component_to_blueprint for Blueprint assets.

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