Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_rig_control_settings

DestructiveIdempotent

Edit an existing Control Rig control's shape, gizmo, color, and limit-draw settings that can't be set after creation. Applies changes, recompiles, and verifies.

Instructions

Edit an existing Control Rig control's shape/gizmo/color/limit-draw settings (the bits add_rig_control can't set afterwards). Read-modify-write: reads the control's FRigControlSettings, applies the provided fields, writes back via URigHierarchyController::SetControlSettings, recompiles + saves, and returns the verified read-back. Only the supplied fields change.

Returns: { asset_path: string, control_name: string, settings_applied: { display_name, shape_name, shape_color: [float], shape_visible, draw_limits }, 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.
shape_nameNoOptional gizmo shape name (e.g. "Default", "Box", "Sphere", "Circle").
draw_limitsNoOptional bool: whether to draw the control's limits in debug.
shape_colorNoOptional shape color [R, G, B] or [R, G, B, A] floats (0..1).
control_nameYesName of an existing control element.
display_nameNoOptional display name (FName) for the control.
shape_visibleNoOptional bool: whether the gizmo shape is visible in 3D.
control_rig_pathYesPath to the UControlRigBlueprint asset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the read-modify-write mechanics, the internal write path (URigHierarchyController::SetControlSettings), the recompile+save side effect, the read-back verification, and that only supplied fields change. Annotations only flag destructive/idempotent; this description explains what is actually mutated and persisted.

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-loads the purpose, then mechanics, then a terse Returns block. Dense but tight; every sentence carries information, though the engine-level detail (FRigControlSettings, URigHierarchyController) is slightly more than an agent needs to select the tool.

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?

Mutation tool with 8 params and no output schema; the description compensates with a compact Returns shape, the compile/save side effects, and the PIE restriction. Safety profile is covered by annotations, so the definition is essentially complete for correct invocation.

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% (including a detailed force/PIE warning), so the schema already carries the load. The description adds 'only the supplied fields change,' which clarifies the partial-update semantics of the optional params, but nothing else beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Edit/set) and resource (an existing Control Rig control's shape/gizmo/color/limit-draw settings), and explicitly carves scope against add_rig_control ('the bits add_rig_control can't set afterwards'). It does not disambiguate from overlapping siblings like set_rig_control_shape_transform and set_rig_control_limits, so it falls short of a 5.

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?

Frames this as the post-creation editing tool for settings add_rig_control cannot set, and the force param spells out the PIE prohibition with the recommended action (stop PIE and retry). Clear context, but no explicit routing vs the adjacent set_rig_control_limits/shape_transform tools, so no exclusions in the description itself.

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