godot-omni

Overview Schema Source Related Servers Discussions Admin

animation_manage

Create and manage Godot AnimationPlayer clips, adding property/method tracks, setting autoplay, and applying fade/slide/shake/pulse presets.

Instructions

AnimationPlayer authoring (player, tracks, autoplay, presets, playback).

Ops: • player_create(parent_path, name="AnimationPlayer") Create an AnimationPlayer with empty default library. • delete(player_path, animation_name) Delete an animation clip from the default library. Undoable. • validate(player_path, animation_name) Check all track paths resolve. Returns broken_count + per-track issues. • add_property_track(player_path, animation_name, track_path, keyframes, interpolation="linear") Add a property track. track_path: "NodeName:property". keyframes: [{time, value, transition?}, ...]. interpolation: linear|nearest|cubic. • add_method_track(player_path, animation_name, target_node_path, keyframes) Add a method track. keyframes: [{time, method, args?}, ...]. • set_autoplay(player_path, animation_name="") Set autoplay. Empty animation_name clears. • play(player_path, animation_name="") Editor preview. Not saved with scene. • stop(player_path) Stop editor preview. Not saved with scene. • list(player_path) List animations with length, loop_mode, track_count. • get(player_path, animation_name) Inspect a clip's tracks and keyframes in detail. • create_simple(player_path, name, tweens, length=None, loop_mode="none", overwrite=False) High-level: build a multi-track clip from tween specs in one call. tweens: [{target, property, from, to, duration, delay?, transition?}]. • preset_fade(player_path, target_path, mode="in", duration=0.5, animation_name="", overwrite=False) One-call fade-in/out (modulate.a). • preset_slide(player_path, target_path, direction="left", mode="in", distance=None, duration=0.4, animation_name="", overwrite=False) One-call slide-in/out (position). • preset_shake(player_path, target_path, intensity=None, duration=0.3, frequency=30.0, seed=0, animation_name="", overwrite=False) One-call shake (jittered position). • preset_pulse(player_path, target_path, from_scale=1.0, to_scale=1.1, duration=0.4, animation_name="", overwrite=False) One-call pulse / hover-bounce (3-keyframe scale ping-pong).

Preset target_path: accepts either a scene-absolute path (e.g. "/Main/World/Cube", matching every other scene tool) or a path relative to the AnimationPlayer's root_node (e.g. "World/Cube", matching how Animation tracks store node paths). Scene-absolute targets outside the player's root_node subtree are converted to a ..-prefixed track path via root_node.get_path_to(target), the same shape the relative form already accepts.

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`op`	Yes
`params`	No
`session_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.1.0Sep 17, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and largely succeeds: it discloses that delete is undoable, play/stop are editor previews not saved with the scene, validate returns issues, and presets support overwrite. It also explains target_path resolution and the canonical call shape. However, preset_bounce and preset_spin appear in the op enum but are missing from the description, leaving those behaviors undisclosed.

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 long but appropriately structured: a scannable bulleted op list with compact signatures, followed by essential clarifications about target_path and call shape. Each line carries necessary information, and the formatting makes complex multi-op semantics easy to navigate.

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?

For a complex tool with a sparse schema and no annotations, the description covers most operations thoroughly and even mentions return values for list/get/validate. However, it omits two valid operations from the schema enum, preset_bounce and preset_spin, making the definition incomplete for an agent that needs to invoke every available operation correctly.

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

Parameters5/5

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

The input schema is nearly empty (op enum plus a generic params object, 0% coverage), so the description is the only parameter documentation. It provides full signatures, defaults, valid interpolation values, keyframe object shapes, tween specs, preset parameters, and path conventions. For every documented operation, the parameters are specified precisely enough to call correctly.

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 opens with 'AnimationPlayer authoring' and enumerates specific operations (player_create, add_property_track, set_autoplay, presets, playback, etc.), each with a verb and target resource. It clearly distinguishes itself from generic animation/resource tools by focusing on AnimationPlayer node authoring and manipulation.

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

Usage Guidelines3/5

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

Usage is implied through the 'AnimationPlayer authoring' scope and intra-tool distinctions like 'High-level' for create_simple and 'One-call' for presets. However, there is no explicit guidance on when to choose this tool over sibling tools such as animation_create, and no when-not-to-use or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.