Retrieves an animated object's NLA tracks and strips from top to bottom, including action, frame range, blend mode, and repeat settings for animation review.
List an object's NLA tracks and strips, top to bottom.
Args: object_name: Animated object.
Returns: Dict with each track and its strips (action, frames, blend, repeat).
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v3.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden; 'List' plus 'top to bottom' conveys it is a non-mutating read and discloses the ordering of results. However, it says nothing about behavior for objects without NLA data, missing objects, or permissions, so it is only partially complete.
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 one-line summary is front-loaded and the Args/Returns blocks are terse with no filler. The boilerplate section headers are slightly formulaic but not wasteful.
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?
For a low-complexity read tool with an output schema available, this is essentially sufficient: it names the input, states the ordering, and gestures at the return shape. Only edge-case behavior (empty NLA stack, invalid object) is unaddressed.
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 coverage is 0% for the single parameter, so the description must compensate; it does so only with the gloss 'Animated object'. That adds real semantic meaning (the object must have animation data) but gives no hint about accepted formats or whether an active-object shortcut exists.
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?
The description gives a specific verb and resource ('List an object's NLA tracks and strips') and even states the ordering (top to bottom), so the operation is unmistakable. It does not reference the nearby siblings list_strips or add_nla_strip, so the agent gets no help distinguishing NLA-track listing from strip-level listing.
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?
There is no statement of when to use this versus alternatives, no prerequisites, and no exclusions. The only implicit signal is that the target must be an 'Animated object', which is a constraint rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.