Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

attach_blueprint_component

Destructive

Parent an SCS component under another component, native root, or inherited native scene component so sockets on inherited meshes become reachable.

Instructions

Parent an existing SCS component under another component (or the native root). The parent may be an SCS component of this Blueprint OR a NATIVE inherited scene component from a parent C++ class (e.g. ACharacter's "CharacterMesh0" or the native capsule) -- when the name is not an SCS node and is not the native root, it is resolved from the parent-class CDO and the child is parented to it natively (bIsParentComponentNative=true). This makes sockets on inherited native meshes reachable (e.g. a socket under CharacterMesh0 at "spine_4", or a ChildActor attached at "spine_2").

Returns: { blueprint_name, component_name, parent, parent_is_native, attach_socket, already_attached }

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.
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 of the SCS component to attach (the child)
parent_component_nameNoOptional parent component name; omit / "root" / the native root name attaches to the native root component. May also name a NATIVE inherited scene component (e.g. "CharacterMesh0") to parent the child natively to it.

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 declare destructiveHint=true and non-idempotent, so the safety profile is covered. The description adds genuinely new behavioral context: when a name is neither an SCS node nor the native root it is resolved from the parent-class CDO and parented natively (bIsParentComponentNative=true), plus the returned field set. It does not restate the PIE-refusal constraint, which lives in the schema.

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 core action, then the parent-resolution rule, then the return shape. The middle sentence is long and parenthetical-heavy, but every clause carries real information and nothing is padding.

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 usefully lists the returned fields, and with full schema coverage plus annotations the agent has what it needs to call the tool. The one gap is that usage/selection guidance against sibling component tools is absent.

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 six parameters, including the native-parent option and socket_name. The description reinforces the parent_component_name semantics (native inherited meshes, native root) but adds little beyond what the schema fields already state, so the baseline 3 holds.

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 ('Parent an existing SCS component under another component or the native root') and scopes it to an existing component rather than a new one, which cleanly separates it from add_component_to_blueprint and remove_component_from_blueprint. The native-vs-SCS parent distinction further pins down the exact operation.

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 description explains the parent-resolution behavior but never says when to reach for this tool over alternatives (e.g. add_component_to_blueprint, attach_actor, or the other Blueprint component tools). Usage is only implied by the mechanics described.

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