Skip to main content
Glama
Sign In
o3de-mcp

o3de-mcp

by nickschuetz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

add_anim_graph_node

Adds a node to an O3DE animation graph, selecting its type and optional parent, name, and canvas position. Returns the created node or rejects unknown node types.

Instructions

Add a node to an anim graph.

Returns the new node object exactly as get_anim_graph emits it. An unknown node_type is refused with the list of known types.

Args: anim_graph_id: Graph id (number or digit string). node_type: RTTI or palette name, case-insensitive (for example AnimGraphMotionNode, AnimGraphStateMachine, BlendTree, BlendTreeBlend2Node). parent_id: Parent node id (a state machine or blend tree). Defaults to the root state machine. name: Node name. The engine generates one when omitted. position: [x, y] graph-canvas position in integer pixels.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "anim_graph_id": "<anim_graph_id>",
      "node_type": "<node_type>"
    },
    "name": "add_anim_graph_node"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
positionNo
node_typeYes
parent_idNo
anim_graph_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4/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 behavioral burden and does reasonably well: it discloses the return value (the new node as get_anim_graph emits it), the error path (unknown node_type refused with the list of known types), the name-generation default, and the parent default (root state machine). It stops short of stating permission/auth requirements or whether the node can be undone.

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-loaded with the purpose, then the return contract and error behavior, then a clean Args section. Given the 0% schema coverage, the length is justified; almost every sentence adds information an agent needs.

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?

For a mutation tool with no annotations and a totally undescribed schema, the description covers purpose, arguments, defaults, and error behavior thoroughly. It even restates the return contract despite an output schema existing. The main residual gap is permission/undo semantics, which the sibling undo/redo tools make relevant.

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?

Schema coverage is 0%, so the description must compensate and it does: it explains formats for all five parameters, including accepted id forms (number or digit string), case-insensitive RTTI/palette node_type names with concrete examples, the parent-id domain (state machine or blend tree), and the position array as [x, y] integer pixels.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Add a node to an anim graph") that an agent can readily distinguish from sibling operations like add_anim_graph_parameter, add_anim_graph_transition, and connect_anim_graph_ports. It does not explicitly name which sibling to prefer, but the resource is unambiguous.

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 by the description (you call it to create a new node, with node_type/parent_id selecting what kind and where). However, there is no explicit when-to-use guidance, no mention of set_anim_graph_node for modifying an existing node, and no exclusions. It leaves the routing to inference.

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