Skip to main content
Glama

add_component_to_actor

Idempotent

Attach a new component to an actor already placed in the level, returning its object path for immediate property or function setup. Use idempotent=true to avoid duplicates.

Instructions

Attach a new component of a given class to an actor ALREADY PLACED in the level (an instance-level component, not a change to its Blueprint -- for that use add_component_to_blueprint, which affects every instance). Returns object_path, the full reflection path to feed straight into set_property_value / call_function to configure it, so no dedicated add_* wrapper is needed. Pass idempotent=true to make re-running safe. Editor world only; the change dirties the actor's package, so save_level to keep it.

Returns: { actor_name: string, component_name: string, object_path: string, requested_component_name: string, component_type: string, already_existed: bool, success: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scaleNoOptional [x, y, z] relative scale (for scene components)
locationNoOptional [x, y, z] relative location (for scene components)
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] relative rotation (for scene components)
actor_nameYesName of the placed actor to add the component to (editor world).
idempotentNoOptional bool (default false). When true, if the actor already has a component of this class, return it instead of adding a duplicate (already_existed:true). Use for single-instance components.
component_nameYesName to assign to the new component
component_typeYesComponent class name (e.g., 'StaticMeshComponent', 'BoxComponent', 'UStaticMeshComponent')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, and the description reinforces idempotency while adding traits the annotations do not carry: editor-world-only constraint and that the change dirties the actor's package requiring save_level. It also explains object_path can be fed into set_property_value/call_function.

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?

Purpose is front-loaded in the first clause, followed by sibling differentiation, return value usage, idempotency, and a persistence note. Every sentence earns its place with no filler.

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

Completeness5/5

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

No output schema exists, but the description explicitly enumerates the return fields and the key object_path semantics. Combined with the world restriction, idempotency, and save requirement, an agent has everything needed to invoke and follow up correctly.

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 seven parameters (including a detailed rotation warning). The description adds only the idempotent=true usage hint, which is already covered in the schema text, so baseline 3 applies.

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 (attach) and resource (component of a given class) and precisely scopes it to an actor ALREADY PLACED in the level. It explicitly names the sibling add_component_to_blueprint and contrasts instance-level vs Blueprint-level changes, so an agent can choose between them without opening either 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 the alternative (add_component_to_blueprint) with the exact condition that selects it, notes editor-world-only execution, instructs to pass idempotent=true for safe re-runs, and tells the agent to save_level to persist. Full when/when-not/alternative coverage.

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