Skip to main content
Glama

set_rig_control_shape_transform

DestructiveIdempotent

Adjusts the local gizmo transform of an existing Control Rig control, overriding only the location, rotation, or scale you supply, then recompiles and saves the verified result.

Instructions

Set the local shape (gizmo) transform of an existing Control Rig control. Reads the current local shape transform, overrides only the supplied location/rotation/scale, writes back via URigHierarchy::SetControlShapeTransform, recompiles + saves, and returns the verified read-back. This positions the manipulator gizmo relative to the control, independent of the control's value.

Returns: { asset_path: string, control_name: string, shape_transform: { location: [float], rotation: [float], scale: [float] }, applied_count: int, saved: bool, save_error?: string }

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] gizmo scale.
locationNoOptional [X, Y, Z] gizmo location.
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] gizmo rotation.
control_nameYesName of an existing control element.
control_rig_pathYesPath to the UControlRigBlueprint asset.

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?

The annotations only declare it is a non-read-only, destructive, idempotent write. The description goes well beyond that: it discloses the exact read-modify-write sequence, that it writes via URigHierarchy::SetControlShapeTransform, that it recompiles and saves the asset, and that it returns a verified read-back. That is precisely the side-effect information an agent needs before mutating an asset.

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?

Three tightly packed sentences front-load the purpose, then mechanism, then the gizmo-vs-value distinction, followed by an explicit return shape. Since there is no output schema, including the Returns block is earned rather than redundant.

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 destructive, non-idempotent-looking-but-actually-idempotent mutation on a Control Rig asset, everything an agent needs is present: required params, PIE safety guidance, side effects (recompile + save), and the return shape. Nothing material is left to inference.

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 description coverage is 100%, so the baseline is 3 and the individual params (location/rotation/scale/force) are already documented in-schema. The description still adds the meaningful partial-update semantic — 'overrides only the supplied location/rotation/scale' — and clarifies these are gizmo-space values, which the schema text does not spell out.

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 — the local shape (gizmo) transform of an existing Control Rig control — and then distinguishes it from the far more common sibling operation by noting it works 'independent of the control's value' (unlike set_rig_control_value). An agent can tell this apart from the other rig setters without opening any schema.

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?

Explains the operational context clearly: read-modify-write with only supplied axes overridden, plus the PIE refusal condition carried in the schema's force param. It does not explicitly name an alternative sibling or a when-not-to-use-this rule beyond PIE, so it falls short of the 5 tier, but the gizmo-vs-value framing gives strong routing context.

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