Skip to main content
Glama

set_pose_asset_base_pose

DestructiveIdempotent

Set or reset a UPoseAsset's base pose by name, saving through an undo transaction; an empty name uses the skeleton reference pose.

Instructions

Set which named pose of a UPoseAsset is its base pose (UPoseAsset::SetBasePoseName) in an undo transaction, then save the asset; an empty or None base_pose_name goes back to the skeleton reference pose. A name the asset does not contain is an error before anything changes, and so is a base pose the engine does not take (read back from the asset), with nothing saved. The base pose the asset already has is a success with applied=false and saved=false, and nothing is modified or saved. A failed save makes success false, with saved=false and save_error. The base pose only drives evaluation of an additive pose asset, which additive and note report. Edit poses with add_pose_to_pose_asset, rename_pose_in_pose_asset and remove_pose_from_pose_asset.

Returns: { pose_asset_path, base_pose_name, requested_name, applied, base_pose_index, is_reference_pose, additive, note, saved, save_error, message }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
base_pose_nameNoName of the pose to use as the base; empty/None resets to the reference pose.
pose_asset_pathYesPath to the UPoseAsset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The description richly discloses behavior beyond the annotations: it runs in an undo transaction, saves the asset, distinguishes pre-change errors from no-op success, reports save failures via save_error, and explains that the base pose only affects additive pose evaluation. The annotations already mark it destructive/idempotent, and the description adds meaningful operational context without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded: the first sentence states the action and save behavior, followed by error, no-op, save-failure, and dependency details. Every sentence adds operational information, and related tools are listed at the end without extra prose.

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?

With no output schema, the description compensates by listing the return fields inline and explaining the key result flags applied, saved, save_error, and note. For a tool with two parameters and clear annotations, the description covers error paths, no-op behavior, save semantics, and related tools sufficiently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters, establishing a baseline of 3. The description adds meaning beyond schema for base_pose_name by describing error behavior for names the asset does not contain and names the engine does not accept, plus the no-op case.

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: set which named pose of a UPoseAsset is its base pose, then save. It also names the underlying engine call and distinguishes the action from nearby pose-editing siblings like add_pose_to_pose_asset, rename_pose_in_pose_asset, and remove_pose_from_pose_asset.

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 clear conditions: empty/None resets to the reference pose, invalid names fail before changes, and setting the existing base pose is a no-op success. It also points to alternatives for editing poses, but it does not explicitly frame when this tool should be chosen over those alternatives beyond the narrower base-pose purpose.

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