Loading ToolBench
An MCP server that provides tools and resources for working with Universal Scene Description (USD) and NVIDIA Omniverse, enabling USD stage creation, manipulation, physics simulation, and animation
This server has substantial definition quality gaps across all tools. While tool names follow a clear verb_noun pattern and most have descriptions, the descriptions are often generic and underdescriptive. Parameter schemas are present but lack critical validation constraints (enums, ranges, patterns). Output schemas are entirely undocumented. Error handling is minimal, tools return JSON strings rather than structured error responses with recovery guidance. The server lacks parameter type definitions in critical cases (e.g., 'gravity' in configure_physics_scene is described as 'optional dictionary' with no formal schema). No tool implements idempotency semantics, confirmation steps for destructive operations, or detailed recovery guidance. Most tools average 25-40 chars in description length, well below the 50-200 char optimal range for LLM tool selection.
Analyze a USD stage and return information about its contents
Close and unload a stage, freeing resources
Configure a physics scene's properties
Create a complete animation with multiple keyframes by stage ID
Create a new USD stage with optional template
Create a complete transform animation (translation, rotation, scale) by stage ID
Get the properties of a physics scene
Output schemas are completely undocumented. No tool declares what fields it returns, forcing LLMs to guess at response structure and risk parsing errors. This violates the pattern:tool requirement for documented return types.
Parameter 'gravity' in configure_physics_scene is documented as 'optional dictionary' with no formal schema, type definition, or nested field descriptions. LLMs cannot validate the structure and will guess at the correct format (direction as list vs array, magnitude as float vs string).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
List all prims under a given path in the stage
Open an existing USD stage or create it if requested
Save a stage if it has been modified
Set a keyframe for an attribute at a specific time by stage ID
Create a physics scene on a stage identified by ID
Destructive operations (create_new_stage, save_usd_stage, close_stage, all animation/physics writes) lack confirmation steps, dry-run modes, or explicit 'destructive' annotations. Agents may execute irreversible changes without user confirmation.
Tool descriptions are consistently short (30-50 chars) and lack context for LLM selection. E.g., 'Analyze a USD stage and return information about its contents' does not explain when to call it instead of list_stage_prims, what 'information' means, or what structure is returned. Baseline optimal range is 50-200 chars.
No parameter has enum constraints for known finite sets (e.g., 'template' in create_new_stage allows 'empty' or 'basic' but is not declared as enum). 'up_axis' accepts 'Y' or 'Z' but is not constrained. Free-form strings invite hallucinated invalid values.
Error handling returns JSON strings ('error_response()') rather than structured MCP error objects. Errors do not categorize as retryable, user-fixable, or fatal, nor do they guide recovery. Example: 'Stage not found: <stage_id>' gives no next step; should suggest 'Call list_stages() to see available stages' or 'Call create_new_stage() to create one.'
Parameter 'file_path' in create_new_stage and analyze_usd_stage has no validation rule description. Is it absolute or relative? What file extensions are allowed? What happens if the path already exists or the directory doesn't? LLMs will guess and pass invalid paths.
No pagination support. 'list_stage_prims' returns all prims under a path with no limit or offset parameters. A deep hierarchy could return thousands of prims, exhausting the LLM context window. Should support limit and offset/cursor for pagination.
Tools that accept 'stage_id' do not document what format this ID takes, how it is generated, or how to discover existing stages. No 'list_stages()' or 'get_stage_id()' tool exists to help LLMs find a valid stage_id.
Naming ambiguity: multiple tools use '_by_id' suffix (setup_physics_scene_by_id, set_keyframe_by_id, create_animation_by_id, create_transform_animation_by_id) without a clear alternative. This signals there may be variants (e.g., setup_physics_scene_by_path) that aren't documented, confusing LLM selection.