Removes an animation graph from the O3DE engine, unloading it without deleting its file on disk.
Remove an anim graph from the engine (not its file on disk).
Returns {"removed": <graph id>}.
Args: anim_graph_id: Graph id (number or digit string).
| Name | Required | Description | Default |
|---|---|---|---|
| anim_graph_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries behavioral burden. It discloses two useful traits: it removes from the engine rather than disk, and it returns {'removed': <graph id>}. However, it does not disclose whether the removal is reversible (no undo hint), whether the graph must be loaded/unused, or what happens on an invalid id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: purpose, scope clarification, return value, then arg. Every sentence earns its place, though the return-value line repeats information that the output schema likely already provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 1-param tool with a simple mutation and an output schema present, the description covers the essential scope distinction (engine vs disk) and the arg format. It leaves minor gaps around reversibility and prerequisite state, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents the single parameter as 'Graph id (number or digit string)', which matches the schema's anyOf integer/string and clarifies the string must be digits. This is adequate but minimal for a 1-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Remove an anim graph from the engine') and clarifies scope with the parenthetical '(not its file on disk)'. This distinguishes it semantically from save_anim_graph and delete-type siblings, though it does not name the sibling that deletes from disk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are given. The parenthetical implies you'd use a file-level operation for disk removal, but no sibling is named and no condition is stated for choosing this tool over list_anim_graphs/get_anim_graph or other anim graph operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.