Skip to main content
Glama
Sign In
o3de-mcp

o3de-mcp

by nickschuetz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

create_anim_graph

Creates a new empty in-memory EMotion FX anim graph for authoring, starting with only its root state machine. Use it to begin graph creation before saving or removing.

Instructions

Create a new, empty, in-memory EMotion FX anim graph to author.

Returns {"id": <graph id>, "file_name": ""}. The graph starts with only its root state machine. Save it with save_anim_graph; remove it with remove_anim_graph.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_anim_graph"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that the graph is in-memory, starts empty with only a root state machine, and is not persisted until saved. The return shape is restated from the output schema rather than adding new information, and there is no note on permissions or failure modes.

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?

Three short sentences with zero filler, front-loading the creation action before the return value and lifecycle pointers. Every sentence earns its place.

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 zero-argument creation tool with an output schema, the description covers the initial state, persistence requirement, and teardown path. Nothing an agent needs to invoke it correctly is missing.

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?

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly adds no parameter discussion, which is appropriate here.

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 and resource ('Create a new, empty, in-memory EMotion FX anim graph') and scopes it as an authoring target. Sibling tools like save_anim_graph, remove_anim_graph, and load_anim_graph are named, so an agent can immediately tell which operation this is.

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?

Explicitly routes the agent to the follow-up lifecycle tools ('Save it with save_anim_graph; remove it with remove_anim_graph'), which gives clear usage context for what comes next. It stops short of saying when to prefer this over load_anim_graph for an existing graph.

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