Skip to main content
Glama
whats2000

Isaac Sim MCP Server

get_prim_info

Retrieve detailed prim information including type, children, local and world transforms, rotation, scale, and actual size for geometric prims to reason about distances and contact in Isaac Sim.

Instructions

Get detailed information about a specific prim.

Returns type, children, and a transform block. Position is reported in both frames, under explicit names — there is no bare "position": position_local — parent-relative, the value transform_object writes. position_world — where the prim actually is on the stage. Use this to reason about distances, reach, or contact. For a robot link such as /World/Franka/fr3_hand_tcp the two differ by the robot's own pose. position_world_source is "usd" (derived from the authored transform) or "physics" (measured, on Newton). On Newton a body that has been simulated may carry position_warning saying both values are its spawn pose; read it through get_physics_state instead.

Also returns rotation [rx, ry, rz] in degrees (XYZ order, the same convention transform_object accepts) and scale — both local, like position_local. For geometric prims (Cube, Sphere, Cylinder, Cone, Capsule), also returns actual_size [x, y, z] in meters accounting for scale and default primitive dimensions (world-space, like position_world).

Args: prim_path: The USD prim path to inspect.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prim_pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden — and it delivers richly. It discloses the dual-frame convention (position_local vs position_world), the source semantics ('usd' vs 'physics'), the position_warning caveat on Newton, the rotation ordering (XYZ degrees, matching transform_object), local vs world scaling, and the actual_size behavior for geometric prims. This is far beyond the minimum and leaves the agent with no dangerous assumptions about output semantics.

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 description is longer than average, but every sentence earns its place — the framing notes prevent real errors (bare 'position' confusion, wrong reference frame, spawn-pose misreads). It is front-loaded with the purpose, uses a scannable bullet layout, and avoids fluff. It is verbose by necessity, not by 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?

An output schema exists, so return-value structure need not be spelled out — yet the description goes further and explains the semantics of the returned fields (frame meanings, source values, warning conditions, unit conventions). For a single-parameter read tool this is essentially complete; the only minor omission is error behavior for invalid prim paths, which is not critical here.

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 description coverage is 0%, so the description must compensate, and it does. The single parameter prim_path is given meaning beyond the schema title: 'The USD prim path to inspect,' which clarifies the expected path format. For a one-parameter read tool this is adequate compensation; it could add examples of valid path forms (e.g., /World/Franka/fr3_hand_tcp), but the coverage gap is small since there is only one simple parameter.

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+resource ('Get detailed information about a specific prim') and lists exactly what is returned: type, children, transform block. The explicit 'there is no bare position' note preempts a common agent mistake and differentiates this read tool from siblings like get_robot_info, get_scene_info, and get_simulation_state. An agent can tell what this tool does and what it is not without opening another schema.

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

Usage Guidelines4/5

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

Provides explicit usage context ('Use position_world to reason about distances, reach, or contact') and one concrete routing to a sibling ('read it through get_physics_state instead' for the Newton spawn-pose warning case). It also references transform_object's convention to tie related tools together. It does not, however, broadly contrast with the many other read siblings (get_scene_info, get_simulation_state, get_robot_info), so the exclusion guidance is present but not comprehensive.

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