Skip to main content
Glama

create_object

Creates primitive 3D objects (Cube, Sphere, Cylinder, Cone, Capsule, Plane) in Isaac Sim with precise size, position, rotation, color, and physics options.

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.

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.

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
NameRequiredDescriptionDefault
sizeNo
colorNo
scaleNo
positionNo
rotationNo
prim_pathNo
command_idNo
object_typeNoCube
idempotency_keyNo
physics_enabledNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so excellently. It explains surprising behavior such as `scale` being a raw multiplier of native size rather than meters, the precedence of `scale` over `size`, and native sizes per primitive. It also discloses return values (prim_path, actual_size, bounding_box) to help the agent place objects accurately.

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 long but every section earns its place: the size/scale distinction is a critical pitfall, the return-value note is actionable, and the Args list is tidy and consistent. It is front-loaded with the primary purpose and the most surprising behavioral warning.

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 10 optional parameters, no schema descriptions, and an output schema, the description is remarkably complete. It covers supported types, units, defaults, precedence rules, and return semantics. It also gives enough coordinate and color context to invoke the tool correctly without requiring external knowledge.

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 is the only source of parameter meaning. It fully compensates by documenting object_type, position, rotation, scale, size, color, physics_enabled, and prim_path with units and behavioral notes. The only undocumented parameters are command_id and idempotency_key, which are generic execution-flow parameters and not central to object creation semantics.

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 plus resource: "Create a primitive object (Cube, Sphere, Cylinder, Cone, Capsule, Plane)." This makes the tool's scope unambiguous and clearly distinguishes it from sibling creation tools like create_light, create_robot, or create_material.

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?

The description clearly establishes when the tool is appropriate: whenever a primitive object is needed. It also provides strong internal guidance on choosing `size` over `scale`, explaining when scale is appropriate for non-uniform shaping. It does not explicitly name alternative tools to use instead, but the context is clear enough.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Tim0320/IsaacSim-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server