Skip to main content
Glama
whats2000

Isaac Sim MCP Server

create_physics_scene

Create a physics scene by setting gravity and scene name, adding a ground plane only when the stage lacks one to prevent duplicate collision floors.

Instructions

Create a physics scene, adding a ground plane only if the stage lacks one. Call get_scene_info first to verify connection.

A loaded environment usually brings its own collision floor, and this does not add a second one on top of it — provided load_environment ran BEFORE this call. The check happens once, here: call this first and the environment's floor arrives afterwards, leaving two collision floors with the engine deciding which one objects land on. load_environment reports that case as "collision_floor_warning". The response reports "ground_plane" — the floor objects will actually land on — and "ground_plane_created", false when the stage already had one. Read the floor's height from that prim rather than assuming z=0; an environment's floor is not always at the origin.

The check recognises a collision-enabled prim of type Plane, which is what the shipped environments author. An environment whose floor is a Mesh is NOT recognised, so a second plane is added and two collision floors end up on the stage — which one wins is the physics engine's decision. When "ground_plane_created" is true after loading an environment, verify the floor before placing anything on it.

Args: gravity: Gravity vector [x, y, z]. Default is standard gravity. scene_name: Name for the physics scene prim.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gravityNo
scene_nameNoPhysicsScene

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are present, so the description carries the full burden. It discloses the conditional creation of a ground plane, the response fields ground_plane and ground_plane_created, the risk of duplicate floors, and the limitation with Mesh floors. This goes beyond a simple action statement and reveals side effects and edge cases.

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 long but well-structured. It front-loads the purpose, then gives usage guidance, then behavioral details, then parameter explanations. Each sentence contributes to understanding the tool's behavior and edge cases. While verbose, the complexity of the tool justifies the length; it is not redundant.

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?

The tool has an output schema, so return values are covered. The description covers the key preconditions (get_scene_info, load_environment ordering), the conditional behavior, the response fields, and the risks. An agent has all necessary information to call this tool correctly and interpret results. No critical gaps remain.

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 0%, so the description must explain parameters. It provides an 'Args' section defining gravity as a vector and scene_name as the prim name, but omits the default value for gravity (standard gravity is vague) and does not explicitly state that both parameters are optional, though the schema shows defaults. It adds meaning beyond the schema but could be more precise.

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?

The description opens with a specific verb and resource: 'Create a physics scene' and immediately clarifies the conditional ground-plane logic, which is unique to this tool. It clearly distinguishes this from sibling creation tools like create_object or create_material by focusing on physics scene setup and the environment interaction.

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?

Explicitly instructs to call get_scene_info first to verify connection, and explains the ordering requirement relative to load_environment. It states the consequence of calling this tool before load_environment (two collision floors) and warns about Mesh floors not being recognized. This provides clear when-to-use and precautionary guidance.

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