Skip to main content
Glama

add_component_to_blueprint

Add a component to a Blueprint's SCS with optional relative transform and parent, then compile. Verify placement with get_blueprint_scs_tree, as the tool may report success without persisting.

Instructions

Add a component to a Blueprint's SCS (engine class or a Blueprint AC_* class) with an optional relative transform and parent, then compile. TRAP 1: on a CHILD Blueprint whose scene root is INHERITED, a SCENE component can end up written into the PARENT's SCS (source:"inherited", owner_class = the parent) -- which silently edits a vendor/library asset; non-scene ActorComponents land correctly on the child. TRAP 2: a scene component of a BLUEPRINT class, or one given a location, can report success without persisting and then materialize LATER as a duplicate. Both have the same oracle: get_blueprint_scs_tree right after, checking owner_class and source of the new node -- never the return value.

Returns: { component_name: string, component_type: string } -- an ECHO of the request with no owner, no source and no verification. It says nothing about WHERE the node landed: read get_blueprint_scs_tree afterwards.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoOptional. This command is REFUSED while a Play-in-Editor session is running: it either compiles a Blueprint (the reinstancer can retain a world, and CheckForWorldGCLeaks is Fatal -- it KILLS the editor) or writes to disk (Editor.AllowSavingAssetsDuringPIE=0 makes the engine refuse the write, so it would report success without writing a byte). Stop PIE and retry instead; force=true runs it anyway, at your own risk.
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
transformNoOptional {"location":[x,y,z], "rotation":[p,y,r], "scale":[x,y,z]} alias for scene components; any flat location/rotation/scale arg above wins over the matching axis in here if both are given.
socket_nameNoOptional socket/bone name on the parent (AttachToName)
blueprint_nameNoName of the blueprint
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
component_nameYesName for the new component instance
component_typeYesComponent class: a native short name ('StaticMesh', 'Box', 'Sphere'), a /Script path ('/Script/Engine.StaticMeshComponent'), OR a Blueprint component class given as its object path ('/Game/.../AC_Foo.AC_Foo_C'), a bare package path ('/Game/.../AC_Foo'), or a bare '<Name>_C' ('AC_Foo_C').
parent_component_nameNoOptional parent for scene components; omit / "root" attaches under the Blueprint's EXISTING scene root (SCS or native) instead of force-adding a second orphan root node. May also name a NATIVE inherited scene component (e.g. ACharacter's "CharacterMesh0"), mirroring attach_blueprint_component. Ignored for non-scene ActorComponents (no transform, no hierarchy to join).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the generic safety profile (not read-only, not destructive, not idempotent). The description adds substantial behavioral context beyond that: TRAP 1 describes silently editing a parent/vendor asset when the scene root is inherited, and TRAP 2 describes fake-success writes that later duplicate, plus the PIE refusal/compile-kill risk. This is exactly the kind of non-obvious hazard disclosure the dimension rewards.

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?

The purpose and the failure modes are front-loaded, and each sentence carries real operational weight (traps, oracle, return-value caveat). It is dense and long, but unlike padding, the length is justified by the tool's hazardous behavior; a slight tightening of the two trap paragraphs would help.

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?

With no output schema, the description takes responsibility for the return value—explaining it is a bare echo with no owner/source—and supplies the verification path via get_blueprint_scs_tree. For an 11-parameter mutating tool with hidden failure modes, this is complete enough to call correctly and verify afterwards.

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

Parameters4/5

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

Schema coverage is 100%, so the schema carries the parameter documentation (baseline 3). The description still adds semantic weight by tying parameters to outcomes—scene vs non-scene component_type behavior, and 'one given a location' triggering the duplicate trap—which meaningfully supplements the schema.

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 and scope: 'Add a component to a Blueprint's SCS ... with an optional relative transform and parent, then compile.' It distinguishes native vs Blueprint component classes and clearly separates scene vs non-scene behavior, so an agent can tell it apart from siblings like attach_blueprint_component or remove_component_from_blueprint.

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?

Gives explicit post-call guidance ('get_blueprint_scs_tree right after, checking owner_class and source of the new node') and a clear when-not (refused during PIE unless force=true). It does not directly compare against the attach_blueprint_component sibling for choosing between them, only references it in passing, so it falls short of the 5-level 'explicit alternatives' bar.

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