Skip to main content
Glama

open_scene

Destructive

Opens a USD file as the active stage, replacing the current scene and discarding unsaved changes. Use it to load a scene from disk, URL, or asset library before editing or saving.

Instructions

Open a USD file as the stage, in place of the open one, which goes with its unsaved changes.

Use it to work on a scene from a file; new_scene starts an empty stage instead, and save_scene writes the open one, so call save_scene first to keep it. Opening the stage's own file reloads it from disk. It stops the simulation first; a recording that runs stops taking frames, and draw_debug's drawings go. Refused, with the open stage kept, for a file that isn't there or can't be reached, a type USD doesn't open, a local file that holds no USD (a Git LFS pointer, say), or while Kit opens or closes a stage. A file that passes those checks and still fails to load leaves no stage open, and the error says so; an open that takes over 80 s goes on in Kit after the error. Answers the path opened, the stage it replaced, and the stage's up axis, meters_per_unit, default prim and prim count, with a note for an axis or units the file leaves to USD's fallbacks.

Input Schema

NameRequiredDescriptionDefault
file_pathYesThe USD file: a path on Kit's machine, a relative one read from the folder Kit was started in; a URL (omniverse://, https://, file:///); or a path in Isaac Sim's asset library (/Isaac/...)

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.3

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false; the description goes well beyond that by naming what is lost (unsaved changes, running recording frames, draw_debug drawings) and that the simulation is stopped first. It also enumerates refusal conditions (missing/unreachable file, unsupported type, LFS pointer, Kit busy), the no-stage-left-open failure mode, and the 80 s timeout behaviour — unusually rich for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The destructive consequence is front-loaded in the first clause, then alternatives, then failure modes — good ordering with no filler. It is dense and long, but nearly every clause carries operational information an agent needs.

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

Completeness5/5

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

For a destructive, one-parameter stage-replacement operation, everything needed is present: prerequisites, side effects, refusal cases, timeout behaviour, and a summary of returned fields (path, replaced stage, up axis, meters_per_unit, default prim, prim count). An output schema exists, so the return-value sketch is a bonus rather than a requirement.

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

Parameters4/5

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

Schema coverage is 100% and already documents the accepted path forms (local, relative, URL, /Isaac/ asset library), so baseline is 3. The description adds a non-obvious semantic: passing the currently open stage's own file reloads it from disk rather than erroring.

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?

States a specific verb and resource: 'Open a USD file as the stage, in place of the open one.' It immediately contrasts with siblings new_scene (empty stage) and save_scene (writes the open one), so an agent can route correctly without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('work on a scene from a file'), explicit alternatives (new_scene, save_scene), and an actionable prerequisite: 'call save_scene first to keep it.' It also flags the special case where the path equals the current stage's own file (reload from disk).

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