Fab MCP

Overview Schema Source Related Servers Discussions Admin

Preview a prepared rig or clip

asset_preview_animation

Idempotent

Render a prepared GLB from several angles with an optional clip sample time or explicit bone pose, and publish a nonblank contact sheet under the project root.

Instructions

Render a prepared GLB from several angles with an optional clip sample time or explicit bone pose, and publish a nonblank contact sheet under the project root. A missing rendering backend returns an explicit unavailable result instead of claiming success.

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": {
      "prepared": "<prepared>",
      "output": "<output>",
      "projectRoot": "<projectRoot>"
    },
    "name": "asset_preview_animation"
  }
}

Input Schema

Name	Required	Description
`clip`	No
`pose`	No
`times`	No
`width`	No
`angles`	No
`height`	No
`output`	Yes	Output contact-sheet .png path under projectRoot.
`prepared`	Yes	Absolute path to a prepared (rigged or retargeted) GLB.
`priorDigest`	No
`projectRoot`	Yes	Project root that must contain the output.

Output Schema

Name	Required	Description	Default
`bounds`	Yes
`canvas`	Yes
`images`	Yes
`output`	Yes
`reason`	Yes
`status`	Yes
`tracks`	Yes
`backend`	Yes
`animations`	Yes
`boundTracks`	Yes
`sampledTimes`	Yes
`contactSheetSha256`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Sep 14, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already indicate idempotent, non-destructive, and non-read-only behavior. The description adds useful behavioral context beyond those annotations: it publishes a nonblank contact sheet under the project root and explicitly returns an unavailable result if the rendering backend is missing. This clarifies failure modes and output guarantees.

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?

Two dense sentences convey rendering, optional inputs, output location, and failure behavior with no wasted words. Key constraints like 'nonblank' and 'explicit unavailable result' are front-loaded and meaningful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex with 10 parameters and a nested pose object, yet the description leaves significant gaps: no explanation of priorDigest, no definition of what clip references, no clarification on how times interacts with clip vs pose, and no guidance on width/height defaults or constraints beyond the schema. The output schema helps with return value expectations, but the input side remains under-specified for an agent to use this confidently.

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

Parameters3/5

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

Schema description coverage is only 30%, so the description must compensate. It does partially explain angles, clip sampling, bone pose, and contact sheet output, but it leaves width, height, times, clip's reference semantics, and especially priorDigest unexplained. The description adds meaning for several parameters but not enough to fully cover the 10-parameter surface.

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 states a specific action: render a prepared GLB from several angles, optionally sampling a clip or using a bone pose, and publish a contact sheet. It clearly differentiates from sibling tools like asset_inspect_rig and asset_auto_rig by focusing on rendering/preview output rather than inspection or rigging.

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?

The phrasing 'prepared GLB' and 'optional clip sample time or explicit bone pose' implies this is the tool to call after preparation/rigging work, but it never explicitly says when to choose it over siblings like asset_inspect_rig or asset_retarget_animations. There is no when-not-to-use or alternative routing.

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

Deploy Server