R3

Change a texture set: make a new version of it

r3_texture_update

Change a texture set the account owns: its look (controls: seed, scale, colours, contrast, bumpiness, roughness {min, max}, metalness, size, tileWorldSize, height, applied to the set's own recipe; scale multiplies its pattern, so 2 is twice as fine as now) or a whole new recipe (read the current one with r3_texture_read, change it, pass it here). The set itself never changes: the change is saved as a new version under the same name (the user's lists show the latest), with new maps, and every project and release that uses an older version's maps keeps them. Give name only to make a separate copy under that name instead. The same recipe as the latest version saves nothing. The answer names the user's projects still on an older version; put the new set on a material with r3_texture_apply when the user wants it. An invalid change is refused with the path of the problem. Counts as one render toward your hourly texture budget.

Input Schema

Name	Required	Description
`name`	No	Only to make a separate COPY under this name. Default: a new version of the same set, same name.
`setId`	Yes	The set to change (r3_texture_create / r3_texture_read answer it). The account's own.
`recipe`	No	Or a whole new recipe (format "r3-texture-recipe", version 1).
`controls`	No	Changes to its recipe: {seed, scale, colours, contrast, bumpiness, roughness: {min, max}, metalness, size, tileWorldSize, height}.

Output Schema

Name	Required	Description
`maps`	Yes
`name`	Yes
`size`	Yes
`setId`	Yes
`stats`	Yes
`answer`	Yes	This 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.
`version`	Yes
`warnings`	Yes
`unchanged`	Yes
`previousId`	Yes
`previousInUse`	Yes
`tileWorldSize`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 31, 2026

changedInput schema / properties / name / description

Previous value: -"The new set's name. Default: the old name with the next number (\"Gravel 2\")."New value: +"Only to make a separate COPY under this name. Default: a new version of the same set, same name."

addedOutput schema / properties / unchanged
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / version
```
Added value: +{
+  "type": "number"
+}
```

changedOutput schema / required

Previous value: -[
-  "setId",
-  "previousId",
-  "name",
-  "size",
-  "tileWorldSize",
-  "maps",
-  "stats",
-  "warnings",
-  "previousInUse",
-  "answer"
-]New value: +[
+  "setId",
+  "previousId",
+  "name",
+  "size",
+  "tileWorldSize",
+  "maps",
+  "stats",
+  "warnings",
+  "version",
+  "unchanged",
+  "previousInUse",
+  "answer"
+]

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / controls / description

Previous value: -"Changes to its recipe: {seed, scale, colours, contrast, bumpiness, roughness: {min, max}, size, tileWorldSize, height}."New value: +"Changes to its recipe: {seed, scale, colours, contrast, bumpiness, roughness: {min, max}, metalness, size, tileWorldSize, height}."

AddedOct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: the versioning model (old versions' maps stay with existing projects/releases), the copy-vs-version distinction, error behaviour (invalid change refused with the path of the problem), what the answer contains, and a rate-limit note (one render toward the hourly texture budget). Nothing conflicts with readOnlyHint=false or destructiveHint=false — the described behaviour is additive, not destructive, and the no-op case is disclosed rather than hidden.

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?

Front-loads the core action and scope, and every sentence carries real information (versioning, copy mode, no-op, error, budget). It loses a point for being one dense run-on paragraph with deeply nested parentheticals, which makes the control list harder to scan than a short bulleted clause would be.

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 mutation tool with four parameters and nested objects, the description covers the state-transition model, side effects on downstream projects, error and budget behaviour. An output schema exists so return structure needn't be spelled out, yet the description still notes the answer lists projects on an older version — more than sufficient.

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; the description earns more by explaining semantics the schema only enumerates — `scale` multiplies the pattern so 2 is twice as fine as now, roughness is {min, max}, and nested controls are applied to the set's own recipe. The only gap is that `seed`, `colours`, `tileWorldSize`, and `height` get no per-parameter explanation beyond being listed.

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?

Opens with a specific verb+resource ("Change a texture set the account owns") and immediately clarifies the non-obvious semantics: it creates a new version rather than mutating the set. The title's ambiguity ("change") is resolved in the first clause, and it is clearly separable from r3_texture_create (new set) and r3_texture_apply (assign to material).

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

Usage Guidelines5/5

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

Explicitly routes the agent: read the current recipe with r3_texture_read then pass it here; put the result on a material with r3_texture_apply; give `name` only when the user wants a separate copy. It also states a no-op condition (same recipe as latest saves nothing), which is exactly the kind of when-not guidance that prevents wasted calls.

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

All R3 tools Inspect

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

Need Help?