Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_widget_animation_track

Add or reuse a MovieScene property track for a widget property in a UWidgetAnimation; auto-infers float, color, or bool and creates a full-range section for keyframes.

Instructions

Add (or reuse) a MovieScene property track for a widget's property inside a UWidgetAnimation: finds/creates a UMovieScenePossessable bound to the named widget (+ matching FWidgetAnimationBinding), resolves property_path to a top-level reflected property on the widget's class, and adds the matching typed track (UMovieSceneFloatTrack | UMovieSceneColorTrack | UMovieSceneBoolTrack) with a full-playback-range section. track_type="auto" infers from the property's reflected type (FFloatProperty/FDoubleProperty->float; FLinearColor or FSlateColor struct->color; FBoolProperty->bool). Call add_widget_animation_keyframe afterward to place keys. Single-level property_path only (not dotted sub-paths).

Returns: { widget_bp_path: string, animation_name: string, widget_name: string, property_path: string, track_type: string, possessable_guid: string, binding_reused: bool, track_class: string, track_reused: bool, section_class: string, section_created: bool, 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.
track_typeNoOptional "auto" (default) | "float" | "color" | "bool"
widget_nameYesname of the widget (in the SAME WidgetBP's tree) to animate
property_pathYesname of a top-level reflected property on the widget's class (e.g. "RenderOpacity", "ColorAndOpacity")
animation_nameYesobject name OR display label of the target animation
blueprint_nameNoAlias of `widget_bp_path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `widget_bp_path`.
widget_bp_pathNo/Game path of the Widget Blueprint asset

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare write/mutable/not-idempotent, and the description goes further by disclosing idempotent-ish reuse semantics (possessable/binding/track/section reuse flags), the auto type-inference rules, and the single-level path restriction. The PIE refusal risk is documented in the schema, not the description, so the description itself adds substantial but not exhaustive context.

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 mechanics, then the sequencing hint. The typed-track enumeration and type-inference mapping are dense but relevant; slight redundancy with the schema on inference rules keeps it from a 5.

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 helpfully lists the return object fields, and it documents the sequencing with add_widget_animation_keyframe. The PIE-playback preconditions are delegated to the schema parameter, which is acceptable but places a critical safety caveat outside the description.

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%, so the schema already explains every parameter including track_type inference and the force/PIE caveat. The description's main added value is restating the track_type auto-inference mapping, which duplicates the schema; baseline 3 applies.

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?

The description names a specific verb (Add/reuse), a precise resource (MovieScene property track for a widget property inside a UWidgetAnimation), and enumerates the internal steps taken (find/create possessable, resolve property_path, add typed track with full-playback-range section). It is easily distinguished from siblings like add_property_track or add_transform_track_to_binding.

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?

It explicitly instructs the caller to use add_widget_animation_keyframe afterward to place keys, and states the limitation that only single-level property_path is supported (not dotted sub-paths). It does not, however, cover the PIE-refusal workflow or when to prefer add_property_track over this tool.

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