Loading ToolBench
The server implements 8 USD inspection and manipulation tools with reasonable naming (verb_noun pattern) and descriptions. However, there are significant gaps in parameter documentation, output schema definitions, and error handling guidance. Descriptions are present but mostly generic (average ~120 chars, below the 194-char baseline for A+ tools). Parameter descriptions exist but lack detail about constraints, formats, and expected ranges. No explicit output schemas are documented, forcing LLMs to infer response structure. Error handling is minimal, most tools return {'error': '...'} with no recovery guidance. The schema quality varies: tools have input parameters with types and descriptions, but lack comprehensive documentation of what fields agents should expect in responses.
Export a mesh prim as STL or OBJ. Args: path: Path to the USD file prim_path: Path to the mesh prim to export output: Output file path (.stl or .obj) format: Output format - 'stl' (default) or 'obj'
List all materials in the scene with their shader parameters. Returns diffuse color, metallic, roughness, and other PBR properties for each material.
Get detailed attributes, metadata, and material binding for a specific prim. Args: path: Path to the USD file prim_path: Scene graph path, e.g. /World/Body
Get local and world-space transforms for prims. Args: path: Path to the USD file prim_path: Optional specific prim path. Omit to get all xformable prims.
Read the scene graph of a USD file. Returns the full prim hierarchy with types, face counts, and child structure. Supports .usda, .usdc, and .usdz files.
List all variant sets and their options for prims in the scene. USD variants allow switching between different configurations (e.g. material options, LOD levels, regional variants).
No documented output schemas. While tools return dicts (e.g., {'scene': [...], 'up_axis': ..., 'meters_per_unit': ...}), the expected response structure is not formally documented. LLMs cannot reliably plan downstream operations or extract specific fields without knowing the exact response format.
Parameter descriptions lack constraint information. For example, 'prim_path' is described as 'Scene graph path, e.g. /World/Body' but does not document format rules, whether it must start with '/', or examples of invalid paths. The example value may cause LLMs to reuse it literally.
Error responses provide no recovery guidance. When a prim is not found (usd_get_prim returns {'error': 'Prim not found: <path>'}), there is no hint to the LLM about how to discover valid prim paths. Per pattern:recovery-guide, errors should guide next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Get scene statistics: prim count, mesh count, material count, total faces, and bounding box. Returns dimensions in millimeters (assuming the stage uses standard USD units).
Switch a variant selection on a prim. Args: path: Path to the USD file prim_path: Prim that has the variant set variant_set: Name of the variant set variant: Variant to select
usd_export_mesh 'format' parameter has a default ('stl') but the description example uses 'stl' and 'obj', LLMs may assume the description examples are the complete valid set and fail if 'glb' or other formats are added without updating the description.
No explicit idempotency guarantees. Tools like usd_set_variant are write operations but have no documentation of idempotency behavior. If an agent retries after a network timeout, does calling set_variant twice with the same arguments produce two state changes or one? This is critical for agent retry logic.
No mention of prerequisites or dependencies. For example, usd_get_prim requires a valid prim_path, but there is no suggestion that usd_inspect should be called first to discover available paths. Discovery tools should be positioned as prerequisites.