Skip to main content
Glama

procedural_material

Generate procedural node materials for Blender meshes for renders. Bake to images afterward because they don't export to glTF directly.

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

TableJSON 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.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the glTF export limitation, the bake requirement, UV unwrap/smart-project side effect with an `unwrapped` list, object-space vs UV-space behavior for worn_metal, and the eevee vs cycles/bake rendering difference. It does not state permissions or performance/rate characteristics, but for a material-authoring tool that is a minor gap.

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-loaded with purpose and the critical glTF/bake caveat, then organized by kind and parameter. It is long and dense, but nearly every clause carries functional information (defaults, space semantics, renderer caveats), so little is wasted.

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 9-param, no-output-schema, no-annotation tool, the description covers the full calling contract: required fields, kind enum effects, optional params with defaults, UV vs object space, renderer support, the follow-up bake step, and the material/slot naming behavior. 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?

Schema coverage is 0% across 9 params, so the description must compensate and does: it explains color_a/color_b roles per kind, scale as pattern frequency, seed as pattern shift, roughness semantics (and its special meaning for worn_metal), the full `params` sub-key list with defaults, and the `material` name-rebuild behavior plus slot 0 targeting.

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 distinguishes itself from siblings by naming set_material (plain colour/image maps) and bake_maps (glTF path). The seven enumerated kinds further pin down the scope.

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 guidance: use this for procedural patterns, use set_material for plain colour or image maps, and it 'does NOT reach glTF: run bake_maps afterwards'. Also warns to build the model first for worn_metal because neighbour objects darken cavities.

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