Skip to main content
Glama

create_anim_blueprint

Create, compile, and save an Animation Blueprint for a skeleton, returning it unchanged if it already exists; refuses during PIE unless forced.

Instructions

Create an Animation Blueprint (parent UAnimInstance) for a skeleton at package_path/name with the editor factory, compile it and save it; an existing Animation Blueprint at that path is returned unchanged (already_existed=true). Refused while PIE runs unless force=true. Returns asset_path, generated_class and target_skeleton_set.

Returns: { asset_path: string, name: string, skeleton_path: string, generated_class: string, is_anim_instance: bool, target_skeleton_set: bool, created: bool, already_existed: bool, saved: bool, save_error?: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesAsset name for the new Animation Blueprint
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.
package_pathYesUE content folder, e.g. /Game/MyGame
skeleton_pathNoOptional skeleton path; defaults to /Engine/EngineMeshes/SkeletalCube_Skeleton

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 non-read-only, non-destructive, non-idempotent, and the description goes beyond them by disclosing that the tool compiles and saves to disk, that PIE will actually kill the editor or silently fail to write, and that an existing asset is returned unchanged with already_existed=true. The only nuance left unstated is that a failed save surfaces as save_error in the return payload.

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?

The first sentence front-loads the core action, lifecycle, and idempotency behavior, followed by the PIE constraint. It is dense but mostly earns its words; the trailing repeated 'Returns:' block restates identifiers already named in the preamble, which costs a little.

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, spelling out the return fields (asset_path, generated_class, target_skeleton_set, created/already_existed/saved, save_error) is genuinely necessary and present. The PIE hazard, idempotent-existing behavior, and save step are all covered, leaving only minor gaps such as skeleton_path fallback detail.

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% and the force parameter's schema text is already extremely detailed, so the schema carries most parameter meaning. The description adds only the package_path/name composition convention; it does not add semantics for skeleton_path beyond what the schema states, so the baseline 3 is appropriate.

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 states a specific verb and resource ('Create an Animation Blueprint (parent UAnimInstance)'), names the target path semantics, and specifies the full lifecycle (create, compile, save). This distinguishes it clearly from nearby siblings like create_anim_montage, create_anim_sequence, or compile_anim_blueprint 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?

It gives explicit when-not guidance ('Refused while PIE runs') plus the remedy ('Stop PIE and retry instead') and the escape hatch (force=true, 'at your own risk'), and it explains the existing-asset case. What is missing is routing against sibling creation tools (e.g., when to use create_anim_blueprint vs. scaffold_locomotion_animbp or compile_anim_blueprint), so it is strong context but not full alternative selection.

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