Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

add_anim_transition

Create a source-to-target transition in an animation state machine, with optional crossfade, blend mode, bidirectional link, and priority.

Instructions

Create a source->target transition in an anim state machine.

Returns: { anim_blueprint_path: string, machine_name: string, source_state: string, target_state: string, transition_created: bool, already_existed: bool, crossfade_duration: number, blend_mode: string, bidirectional: bool, priority_order: int, transition_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.
to_stateNoAlias of `target_state` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `target_state`.
blend_modeNoOptional EAlphaBlendOption name, e.g. Linear, Cubic, HermiteCubic
from_stateNoAlias of `source_state` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `source_state`.
machine_nameYesName of the state machine that owns both states
source_stateNoName of the source state (transition origin)
target_stateNoName of the target state (transition destination)
bidirectionalNoOptional; also allow the reverse target->source transition
blueprint_nameNoAlias of `anim_blueprint_path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `anim_blueprint_path`.
priority_orderNoOptional evaluation priority (higher wins)
crossfade_durationNoOptional blend duration in seconds (default 0.2)
anim_blueprint_pathNoPath to the UAnimBlueprint asset

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the safety profile is covered. The description adds real behavioral value by documenting the return payload, especially transition_created, already_existed, saved and save_error, which tells the agent the write may be a no-op and may fail to persist. It does not disclose the PIE guard or what happens when a transition between the same pair already exists, and the already_existed field sits in mild tension with idempotentHint=false.

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?

Two sentences plus a returns block, front-loaded with the purpose and with zero filler. The returns list is long but justified because no output schema exists to carry it. Structure is clean and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 correctly picks up the burden of documenting the return shape, and the schema plus annotations cover inputs and safety. What is missing is workflow context: that the machine and source/target states must pre-exist, that this pairs with add_anim_state and remove_anim_transition, and that the edit must be saved. For a 12-parameter mutation tool this leaves a noticeable gap.

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 all 12 parameters including the three aliases (to_state, from_state, blueprint_name) and the PIE `force` warning are already documented in the schema. The description contributes no parameter-level meaning of its own, which earns the baseline 3 rather than more.

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?

The description gives a specific verb and resource: "Create a source->target transition in an anim state machine." That is enough to separate it from remove_anim_transition, add_anim_state, or the state-tree add_state_transition. It stops short of naming any sibling explicitly, so the agent must infer the boundary from the phrase "anim state machine."

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites (the machine and both states must already exist), and no pointer to sibling tools such as remove_anim_transition or add_anim_state. The only routing-adjacent information, the PIE refusal rule, lives in the schema's `force` parameter, not in the description.

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