Skip to main content
Glama

add_subcomponent_possessable

Add a component possessable as a child of an existing Level Sequence binding, record its name, class, and parent, then save the sequence in an undo transaction.

Instructions

Adds a component possessable as a child of an existing binding (possessable or spawnable) of a Level Sequence found by asset name under /Game, in an undo transaction, and saves the sequence; each call adds a new one, named possessable_name or else the component_class text. It records name, class and parent only: no component object is bound to it. To possess an actual component of an editor-world actor use bind_component_to_sequence; for whole actors use bind_actor_to_sequence or add_spawnable_to_sequence. An unknown parent GUID, an unresolvable class, or a class that is not an ActorComponent is an error.

Returns: { sequence_name: string, possessable_guid: string, component_class: string, parent_guid: string, saved: bool, save_error?: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sequence_nameYesName of the level sequence asset.
component_classYesComponent class name (e.g. 'StaticMeshComponent', 'SpotLightComponent').
possessable_nameNoOptional override name for the new possessable.
parent_binding_guidYesGUID of the parent binding (spawnable or possessable).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only the safety profile, but the description adds substantial behavior: it runs in an undo transaction, saves the sequence, adds a new entry on each call (consistent with idempotentHint=false), records name/class/parent only with no component object bound, and enumerates three error conditions (unknown parent GUID, unresolvable class, non-ActorComponent class). This is exactly the context annotations cannot carry.

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 and scope, then routing guidance, then error cases and the return shape. Dense but each sentence carries distinct information; the embedded Returns block is redundant only because there is no formal output schema, so it earns its place.

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?

For a non-idempotent, saving mutation with no output schema, the description covers side effects, the naming default, error conditions, sibling routing, and the exact return fields. Nothing an agent needs to invoke it correctly is missing.

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 baseline is 3, but the description adds real meaning: possessable_name falls back to the component_class text when omitted, parent_binding_guid must reference a possessable or spawnable binding, and component_class must resolve to an ActorComponent or the call errors.

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 precise verb and resource ('Adds a component possessable as a child of an existing binding... of a Level Sequence') and immediately scopes the asset lookup to /Game. It explicitly distinguishes itself from the sibling tools that bind actual components or whole actors, so an agent can select it 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 the alternatives and the conditions that select them: bind_component_to_sequence for a real editor-world component, bind_actor_to_sequence / add_spawnable_to_sequence for whole actors. It also clarifies the metadata-only nature of the operation, which is the key reason to pick it over the binding tools.

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