Isaac Sim MCP Server

by whats2000

Overview Schema Source Related Servers Discussions Admin

create_material

Create a PBR or physics material for objects in an Isaac Sim scene, with optional color, roughness, metallic, and path settings.

Instructions

Create a PBR or physics material.

Args: material_type: "pbr" for visual material or "physics" for physics material. prim_path: Prim path for the material. Auto-generated if not set. material_path: Alias for prim_path. apply_material names this argument material_path, and an unknown argument is dropped silently rather than rejected — so asking for material_path="/World/Looks/Red" used to succeed while creating the material somewhere else entirely, and the follow-up apply_material then failed on a path that was never used. color: [r, g, b] diffuse color (0-1). PBR only. roughness: Surface roughness (0-1). PBR only. metallic: Metallic value (0-1). PBR only.

Input Schema

TableJSON Schema

Name	Required	Default
`color`	No
`metallic`	No
`prim_path`	No
`roughness`	No
`material_path`	No
`material_type`	No	pbr

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 / material_path

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Material Path"
+}

First observedv0.1.0Jun 4, 2026

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses a critical behavioral trap: material_path is an alias for prim_path, and an unknown argument is silently dropped, which previously caused failures. This is exactly the kind of behavioral context that helps an agent avoid a real bug. It doesn't mention side effects or return values, but the output schema exists and the warning is high-value.

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 well-structured with a clear opening line and a bulleted Args list. The material_path warning is a bit long but earns its place because it documents a silent-failure trap. Slightly verbose in the warning, but every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-param tool with 0% schema coverage and no annotations, the description covers the key semantics: material type, path behavior, and PBR-only params. The output schema exists, so return values are covered elsewhere. Missing explicit guidance on what happens when material_type is 'physics' (which params are ignored) is a minor gap, but the description is largely complete.

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. It explains material_type values, prim_path auto-generation, the material_path alias trap, and the PBR-only scope of color/roughness/metallic. This adds meaning beyond the raw schema, though it doesn't give exact value ranges for all params (color range is given, roughness/metallic are not).

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 states a specific verb ('Create') and resource ('PBR or physics material'), and distinguishes the two material types. It also names the sibling tool apply_material, which helps differentiate this creation tool from the application tool.

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 explains when to use this tool (creating materials) and gives a clear warning about the material_path alias pitfall, which is valuable usage guidance. It doesn't explicitly list alternatives or when-not-to-use, but the context is clear enough for an agent to select it appropriately.

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