Skip to main content
Glama
serionist

omniverse-mcp

by serionist
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

execute_script

Destructive

Run Python inside a live Isaac Sim or Omniverse Kit app to inspect and edit USD scenes, control simulation, and return data via a result variable.

Instructions

Execute Python inside the running Kit app (Isaac Sim, USD Composer, ...).

    The script has access to: omni, carb, Usd, UsdGeom, UsdLux, UsdPhysics, Sdf, Gf, mcp.
    Assign to 'result' to return data. stdout/stderr are captured.

    The `mcp` object provides async access to MCP handlers from within scripts.
    Use `await` to call its methods (the script automatically runs as async):

        viewport = await mcp.capture_viewport(width=1280)
        tree = await mcp.scene_tree()
        await mcp.set_camera([5, 3, 5], target=[0, 0, 0])
        result = {"tree": tree["result"]}

    Available mcp methods:
        mcp.capture_viewport(width, height, camera_path)
        mcp.set_camera(position, target)
        mcp.look_at(prim_path, distance, azimuth, elevation)
        mcp.inspect(prim_path, angles, width, height, zoom_offset=0.0, isolate=False)
        mcp.scene_tree(root, max_depth)
        mcp.prim_properties(prim_path)
        mcp.prim_bounds(prim_path)
        mcp.set_transform(prim_path, position, rotation, scale)
        mcp.create_prim(prim_path, prim_type, **kwargs)
        mcp.delete_prim(prim_path)
        mcp.set_material(prim_path, color, opacity, roughness, metallic)
        mcp.sim_control(action)  -- play/pause/stop/step
        mcp.sim_state()
        mcp.get_logs(count, min_level, channel, search)

    Each returns the full handler response dict with "status" and "result" keys.

    Use Context7 MCP (library: isaac-sim/isaacsim) to look up the correct API calls.

Input Schema

NameRequiredDescriptionDefault
codeYesPython to run inside the Kit app; assign to result to return data

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the risk profile is covered structurally; the description adds substantial context beyond that: the script runs in the live app, runs automatically as async, stdout/stderr are captured, and each mcp call returns a dict with status/result. It stops short of stating timeouts, error propagation, or that script effects on the scene are irreversible.

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?

Front-loaded with the purpose and execution environment, and the bulk of the length is the mcp method inventory, which is genuinely needed to write working scripts. The trailing Context7 sentence feels appended and the method list could be tightened, but there is little waste.

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 an arbitrary-code escape hatch with an output schema, the description covers the environment, importable modules, the return convention, async semantics, and the full bridge API surface. Nothing essential for calling it correctly is missing.

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 coverage is 100% and the single 'code' parameter is already documented as 'assign to result to return data'. The description's module list and mcp method signatures add real meaning for what can be written in that parameter, but the baseline for a fully covered single-param schema is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: execute Python inside the running Kit app, and names the host environments (Isaac Sim, USD Composer). However, it never contrasts itself with the many granular siblings (create_prim, set_material, sim_control), so the agent must infer that this is the general escape hatch rather than a specialized tool.

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?

There is clear guidance on how to write the script (assign to 'result', use await, look up APIs via Context7 MCP), but nothing on when to pick this over the ~40 sibling tools that do the same operations individually. Usage is implied by capability listing rather than by explicit routing or exclusions.

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

Deploy Server

Other Tools