Isaac Sim MCP Server

by whats2000

Overview Schema Source Related Servers Discussions Admin

create_object

Creates primitive objects (Cube, Sphere, Cylinder, Cone, Capsule, Plane) in Isaac Sim, with control over position, rotation, size, color, and physics, returning placement data for scene building.

Instructions

Create a primitive object (Cube, Sphere, Cylinder, Cone, Capsule, Plane).

Prefer size for absolute sizing: size is the target in METERS (default 1.0), so size=0.3 gives a 0.3 m object regardless of type.

scale is a RAW MULTIPLIER of the primitive's NATIVE size, not meters. Native sizes: Cube/Sphere/Cylinder/Cone/Capsule = 2 m, Plane = 1 m. So scale=0.5 on a Cube -> 1 m, and scale=[0.4,0.4,0.3] -> a 0.8 x 0.8 x 0.6 m box (0.4 * 2 m), which surprises callers who expect 0.4 m. Use scale only for deliberate non-uniform shaping; otherwise use size. If both are given, scale wins and size is ignored.

For the geometric prims (Cube, Sphere, Cylinder, Cone, Capsule) this returns prim_path, actual_size [x, y, z] in meters, and bounding_box (min/max corners in world coordinates) so you can accurately place other objects relative to this one. A Plane has no such extent and returns prim_path only.

Args: object_type: Type of primitive — Cube, Sphere, Cylinder, Cone, Capsule, or Plane (case-insensitive; "cube" is normalized to "Cube"). position: [x, y, z] world position. rotation: [rx, ry, rz] rotation in degrees. scale: [sx, sy, sz] RAW multiplier of the native size (2 m for most prims, 1 m for Plane). NOT meters. Overrides size. size: Target size in METERS (default 1.0). Absolute; independent of the primitive's native size. Ignored if scale is provided. color: [r, g, b] color values (0-1). physics_enabled: Enable physics on this object. prim_path: Custom prim path. Auto-generated if not provided.

Input Schema

TableJSON Schema

Name	Required	Default
`size`	No
`color`	No
`scale`	No
`position`	No
`rotation`	No
`prim_path`	No
`object_type`	No	Cube
`physics_enabled`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.1Sep 22, 2026

addedInput schema / properties / size

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Size"
+}

First observedv0.1.0Jun 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and meets it: it discloses the non-obvious scale convention (raw multiplier of native size), gives native sizes, and states precedence when both scale and size are provided. It also discloses differing return behavior for geometric prims vs Plane: prim_path/actual_size/bounding_box vs prim_path only.

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

Conciseness5/5

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

The description is front-loaded with the core action and the critical size/scale warning before the Args list. It is long but organized into clear prose and an Args reference, with almost no filler; the repetition of scale caveats is useful emphasis rather than 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?

Given 8 optional parameters, no schema-level descriptions, and no annotations, the description is complete enough to call correctly: it supplies defaults, explains precedence, enumerates supported object types, and describes return fields. The output schema may carry the formal return structure, but the prose adds the needed semantics.

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

Parameters5/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: every parameter is documented with units or value ranges, including object_type normalization, position as world coordinates, rotation in degrees, color 0-1, and the crucial scale/size distinction. This far exceeds the bare schema names.

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 direct verb and resource: 'Create a primitive object (Cube, Sphere, Cylinder, Cone, Capsule, Plane).' The enumerated types make the scope unmistakable and separate it from sibling creation tools like create_robot, create_camera, and generate_3d.

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?

It gives explicit when-to-use guidance for the key parameter choice: 'Prefer `size` for absolute sizing' and 'Use `scale` only for deliberate non-uniform shaping; otherwise use `size`.' It doesn't name sibling tools for non-primitive creation, but the primitive type list and the size-vs-scale rule provide clear usage context.

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