Sceneplane

Apply a texture package as a material

material_from_maps

Destructive

Create a material from a completed textureJobId or validated role-labeled images. Uses explicit UVs, alpha and normal settings; applyToObjects assigns slot zero, assignments targets explicit slots. Commits one revision after validating all targets. Existing UVs are preserved. Returns a durable job plus complete map artifacts on completion.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`roles`	No
`options`	No
`profile`	No		surface
`uvLayer`	No
`uvScale`	No
`projectId`	Yes
`sourceMaps`	No
`assignments`	No
`materialName`	No		Image Material
`textureJobId`	No
`sourceAssetId`	No
`applyToObjects`	No
`baseRevisionId`	No		HEAD
`idempotencyKey`	Yes	Caller-chosen key. Replaying it with IDENTICAL input returns the EXISTING job instead of queueing a second one — a restarted driver adopts its own in-flight work rather than duplicating or orphaning it. Vary the key to force a new job. Full semantics: the same key with DIFFERENT input is rejected with IDEMPOTENCY_CONFLICT (never silently replayed, so a stale result cannot be mistaken for a fresh one). A key is recorded only once a job is actually created, so a request rejected beforehand (validation, APPROVAL_REQUIRED, quota) leaves the key unused and free to reuse. A key bound to a job keeps resolving to that job even after it fails or is cancelled — use a NEW key to genuinely retry cancelled work. Keys live 48 hours and are scoped per principal+deployment+operation, which means they SPAN SESSIONS: a plain descriptive key like "hero-final-1024-v1" will collide with your own run from yesterday and be rejected. Include a project id or a timestamp. This scope used to be stated only in the conflict error, i.e. after the round trip it cost — a field build lost two that way, ~34 hours after unrelated work had taken the same names.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`job`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedSep 27, 2026

addedInput schema / properties / options / properties / roughnessRange / items
```
Added value: +{
+  "maximum": 1,
+  "minimum": 0,
+  "type": "number"
+}
```
addedInput schema / properties / options / properties / roughnessRange / maxItems
```
Added value: +2
```
addedInput schema / properties / options / properties / roughnessRange / minItems
```
Added value: +2
```

removedInput schema / properties / options / properties / roughnessRange / prefixItems

Removed value: -[
-  {
-    "maximum": 1,
-    "minimum": 0,
-    "type": "number"
-  },
-  {
-    "maximum": 1,
-    "minimum": 0,
-    "type": "number"
-  }
-]

addedInput schema / properties / uvScale / items

Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 10000,
+  "type": "number"
+}

addedInput schema / properties / uvScale / maxItems
```
Added value: +2
```
addedInput schema / properties / uvScale / minItems
```
Added value: +2
```

removedInput schema / properties / uvScale / prefixItems

Removed value: -[
-  {
-    "exclusiveMinimum": 0,
-    "maximum": 10000,
-    "type": "number"
-  },
-  {
-    "exclusiveMinimum": 0,
-    "maximum": 10000,
-    "type": "number"
-  }
-]

AddedSep 27, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: it commits a single revision only after validating all targets, preserves existing UVs, and explains slot semantics (applyToObjects writes slot zero while assignments target explicit slots). Given destructiveHint=true, it arguably under-discloses what material slots are overwritten, but the atomicity and UV-preservation notes are substantive context.

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?

Four dense sentences, front-loaded with the creation verb and source options before moving to placement and commit semantics. Little waste, though the final sentence about returning a durable job is partly redundant given an output schema exists.

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

Completeness3/5

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

For a 14-parameter, nested, destructive mutation, the description is only partially complete: it explains sources, slots, and atomic commit, but leaves nearly the whole `options` surface undocumented and does not warn about the destruction implied by destructiveHint=true. Output behavior is covered by the output schema, so the return sentence need not carry weight.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 7% across 14 parameters with a deeply nested `options` object (~20 sub-fields), and the description covers just a handful (textureJobId, role-labeled images, applyToObjects, assignments). The bulk of the configuration surface (tile, packing, seamMode, normalConvention, physicalCoverageMeters, etc.) is left entirely to bare schema names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (create a material) and names the two accepted sources (a completed textureJobId or validated role-labeled images), which is more than a restatement of the title. It does not, however, explicitly distinguish itself from close siblings such as material_from_image or material_recipe, so the agent must infer the boundary.

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

Usage Guidelines3/5

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

Usage is only implied through the source precondition ('completed textureJobId', 'validated role-labeled images'), which hints at when the tool is applicable. There is no explicit when-to-use/when-not guidance and no named alternative for the adjacent cases (material_from_image, material_recipe).

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

All Sceneplane tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?