Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

remove_anim_bone_track

Destructive

Remove a single bone animation track from a UAnimSequence through its data controller, then save the package. Returns whether the track was removed and saved; use get_anim_curve_names to list tracks.

Instructions

Remove the animation track of one bone from a UAnimSequence through its data controller (IAnimationDataController::RemoveBoneTrack, one undo step) and save the package. No track with that bone name is a success with removed=false and nothing saved; a failed save makes success false, with saved=false and save_error. List tracks with get_anim_curve_names.

Returns: { sequence_path, bone_name, removed, saved, save_error }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bone_nameYesName of the bone track to remove; a name no track has removes nothing.
sequence_pathYesAsset path of the UAnimSequence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.2
    • changedInput schema / properties / bone_name / description
      Previous value: -"Name of the bone track to remove (must match an existing track)."New value: +"Name of the bone track to remove; a name no track has removes nothing."
  2. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag destructive/non-idempotent, but the description adds real behavior beyond them: the operation is one undo step, it saves the package as a side effect, a missing bone is treated as success with removed=false and no save, and a failed save yields success=false with saved=false plus save_error. That is exactly the failure-mode detail an agent needs before invoking a mutation.

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 action and scope, then edge-case outcomes, then discovery, then the return shape. Every sentence carries information, though the parenthetical IAnimationDataController::RemoveBoneTrack is engine-internal noise an agent does not need to select or call the tool.

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 two-parameter destructive tool with no output schema, the description supplies the return fields inline, the save/undo side effects, and both success-path edge cases. Nothing material is left for the agent to guess.

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 coverage is 100% and both parameters are already documented in the schema. The description restates the missing-bone behavior for bone_name, which is only marginally additive over the schema note, so the 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?

States a specific verb (remove), a precisely scoped resource (the animation track of ONE bone), the containing asset type (UAnimSequence), and the mechanism (data controller). This is unmistakably distinct from siblings like remove_anim_curve, remove_bone, or remove_anim_notify.

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?

Gives context for pre-call discovery by naming get_anim_curve_names as the way to list tracks, and implicitly scopes usage to a single bone. It stops short of explicit when-not guidance (e.g., how to remove many tracks or whether a whole-sequence deletion sibling exists).

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