Skip to main content
Glama

procedural_material

Destructive

Generate procedural node materials for Blender meshes, including wood, bricks, marble, and worn metal. Bake to images afterward for glTF export.

Instructions

Give meshes a procedural node material for renders. It does NOT reach glTF: run bake_maps afterwards to turn it into images. Kinds: wood (rings, fibres, knots), checker, diamond (knurled bump), bricks (with mortar), noise (mottled), marble (veins), worn_metal (used steel: dirt in cavities, bright edges, scratches, rounded edges). color_a is the main colour, color_b the second (dark grain, mortar, veins, dirt), both '#rrggbb'; each kind has its own when empty. scale is the pattern frequency; seed shifts the pattern. roughness is 0-1; for worn_metal it is the clean metal, dirt and scratches add to it. Patterns lie on the UV map (a mesh without one is unwrapped with smart project and listed in unwrapped), so their size follows the UV islands. worn_metal works in object space instead: no seams, sizes follow the object. Its dirt, edge wear and rounding use ray-traced nodes: seen in cycles and bake_maps, not in eevee, and neighbour objects darken the cavities, so build the model first. params (optional): bump_strength; wood: grain_stretch (6), knots (true), distortion; marble: distortion; bricks: mortar (0.03); noise: detail_scale; worn_metal: dirt (0.6), edge_wear (0.5), scratches (0.3), metallic (1.0), and in metres bevel_radius, wear_width, ao_distance. The same material name rebuilds it. Slot 0 of each mesh gets it. For a plain colour or image maps use set_material.

Input Schema

NameRequiredDescriptionDefault
kindYes
seedNo
namesYes
scaleNo
paramsNo
color_aNo
color_bNo
materialNo
roughnessNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses overwrite semantics ('The same `material` name rebuilds it'), that slot 0 of each mesh is targeted, that a mesh without UVs is smart-projected and listed in `unwrapped`, and that worn_metal's ray-traced dirt/AO renders in cycles and bake_maps but not eevee and is affected by neighbour objects.

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?

Dense and long, but front-loaded with the highest-value caveat (does not reach glTF) and organised into purpose, per-kind, UV/object-space, and params blocks. Nearly every clause carries information an agent needs; only the per-kind parentheticals border on over-detailed.

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 no output schema, the description covers the destructive overwrite behavior, the render-engine limitations, the UV/object-space distinction, and even names the `unwrapped` side-effect field. Nothing needed to invoke it correctly is missing.

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?

With 0% schema coverage and 9 parameters, the description compensates fully: color_a/color_b roles per kind, per-kind empty defaults, scale as pattern frequency, seed as pattern shift, roughness semantics (and its meaning for worn_metal), and a full breakdown of the nested `params` keys with defaults for each kind.

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?

States a specific verb+resource ('Give meshes a procedural node material for renders') and immediately differentiates from siblings by naming set_material ('For a plain colour or image maps use set_material') and bake_maps. The enumerated kinds make the scope unambiguous.

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?

Explicit when/when-not: 'It does NOT reach glTF: run bake_maps afterwards' tells the agent this is not an exportable material, and set_material is named as the alternative for plain colours or image maps. Preconditions for worn_metal ('build the model first') are also stated.

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