Skip to main content
Glama
Sign In

R3

by org.r3js
OverviewDiscussionsAdmin

Put a texture set on a material

r3_texture_apply
Destructive

Wire a texture set to a material in a project: the colour map to map, the normal map to normalMap, the ambient-occlusion / roughness / metalness map to aoMap + roughnessMap + metalnessMap (for a set without metal its blue channel is 0, so a metal map left by an earlier set is replaced and the material's own metalness is kept), the SAME repeat on every map, the material colour white, roughness 1 and metalness 1 for a metallic set (THREE multiplies the colour map by the colour and the roughness map by the roughness: a grey #808080 colour would show the texture at half brightness, the default roughness 0.5 would halve every roughness; the colour's alpha, the opacity, is kept). A Color the material shares with another component is left as it is, and the material gets its own new white Color; the answer says which. Creates one Texture per map, or reuses a Texture of the project already on that image. MaterialStandard / Physical get every map; Lambert / Phong / Toon get map, normalMap and aoMap; Basic is refused (unlit). repeat is how often the tile repeats across the surface (both axes); or give worldSize in metres: a number for a square surface (1000 for a 1 km terrain with 1 m gravel), or {x, y} for its two sides ({"x": 2, "y": 40} for a 2 m × 40 m path), giving repeatX = x / the set's tile size and repeatY = y / it, so a long strip does not stretch the texture. Give neither and the mesh using the material is measured (its own geometry size times its scale, as r3_component_bounds measures; the two largest sides). Kept at once in the project's live copy: every R3 tab with the project open shows it.

Input Schema

NameRequiredDescriptionDefault
setIdYesThe texture set (r3_texture_create answers it).
repeatNoHow often the texture repeats across the surface, on both axes and every map.
materialYesThe material to wire: its entityRef or id (r3_project_load), e.g. "material_ground".
projectIdYesThe project (r3_project_list).
worldSizeNoOr: the surface size in metres, a number (square) or {x, y} (its two sides, e.g. {"x": 2, "y": 40} for a 2 m × 40 m path); repeatX = x / the set's tile size (1 m for the presets), repeatY = y / it. Neither given: the mesh(es) using the material are measured.

Output Schema

NameRequiredDescriptionDefault
seqNo
answerYesThis answer in words: what was done, what R3 measured, decided or refused, and what to do next. The same text as the result's text block. Read it: the fields beside it are the data, this is the guidance.
colourYes
repeatYes
repeatXYes
repeatYYes
scalarsYes
materialYes
measuredYes
texturesYes
projectIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changed
    • changedInput schema / properties / repeat / description
      Previous value: -"How often the texture repeats across the surface (the same on every map). Default 1."New value: +"How often the texture repeats across the surface, on both axes and every map."
    • addedInput schema / properties / worldSize / anyOf
      Added value: +[
+  {
+    "type": "number"
+  },
+  {
+    "properties": {
+      "x": {
+        "type": "number"
+      },
+      "y": {
+        "type": "number"
+      }
+    },
+    "required": [
+      "x",
+      "y"
+    ],
+    "type": "object"
+  }
+]
    • changedInput schema / properties / worldSize / description
      Previous value: -"Or: the surface size in metres; repeat = worldSize / the set's tile size (1 m for the presets), e.g. 1000 for a 1 km terrain."New value: +"Or: the surface size in metres, a number (square) or {x, y} (its two sides, e.g. {\"x\": 2, \"y\": 40} for a 2 m × 40 m path); repeatX = x / the set's tile size (1 m for the presets), repeatY = y / it. Neither given: the mesh(es) using the material are measured."
    • removedInput schema / properties / worldSize / type
      Removed value: -"number"
    • addedOutput schema / properties / colour
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "componentId": {
+      "type": "string"
+    },
+    "made": {
+      "type": "boolean"
+    },
+    "sharedWith": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "componentId",
+    "made",
+    "sharedWith"
+  ],
+  "type": "object"
+}
    • addedOutput schema / properties / measured
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
    • changedOutput schema / properties / repeat / type
      Previous value: -"number"New value: +[
+  "number",
+  "null"
+]
    • addedOutput schema / properties / repeatX
      Added value: +{
+  "type": "number"
+}
    • addedOutput schema / properties / repeatY
      Added value: +{
+  "type": "number"
+}
    • changedOutput schema / required
      Previous value: -[
-  "projectId",
-  "material",
-  "repeat",
-  "textures",
-  "scalars",
-  "answer"
-]New value: +[
+  "projectId",
+  "material",
+  "repeat",
+  "repeatX",
+  "repeatY",
+  "measured",
+  "colour",
+  "textures",
+  "scalars",
+  "answer"
+]
  2. Changed1 schema field changed
    • changedOutput schema / properties / scalars / additionalProperties / type
      Previous value: -"number"New value: +[
+  "number",
+  "string"
+]
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

The description goes far beyond the annotations: it discloses which material types receive which maps, that Basic is refused, that one Texture per map is created or reused, and that shared Color objects are replaced with a new white Color. It also explains destructive side effects (replacing a leftover metal map, forcing the material colour white, preserving metalness), consistent with destructiveHint=true.

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

Conciseness3/5

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

The main action is front-loaded, which is good, but the body is a dense run-on with heavily nested parentheses (the #808080 brightness aside, the alpha-kept clause), making it hard to scan. Most content earns its place, but the structure could be broken into discrete sentences or lines.

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?

For a destructive, open-world mutation with an output schema, the description covers material-type behavior, texture reuse, colour/roughness/opacity consequences, repeat computation, and live-sync scope. Combined with the output schema carrying return values, nothing essential for a correct call is missing.

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 100%, so the baseline is 3, but the prose adds conceptual meaning: the repeatX = x / tile-size and repeatY = y / tile-size derivation and the concrete {x:2,y:40} example explain the intent of `worldSize` beyond the schema wording. It also clarifies that omitting both triggers mesh measurement, tying `worldSize` to observable behavior.

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 ('Wire a texture set to a material in a project') and enumerates exactly which map goes to which slot. It is distinguishable from r3_texture_create/update (which make/edit sets) because it describes the wiring action against an existing material.

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?

It gives strong guidance on choosing between `repeat` and `worldSize` (including examples like a 1 km terrain and a 2 m × 40 m path), but never explicitly states when to reach for this tool versus siblings such as r3_texture_create or r3_texture_update, nor does it name a 'don't use if' condition. Usage is implied rather than stated.

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

All R3 toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources