Skip to main content
Glama
RoxyCoding

Roxy Blender MCP

by RoxyCoding
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

apply_material

Assign physically based materials to Blender objects with presets, procedural grain, and optional weathering effects, no UVs needed.

Instructions

Physically based materials with procedural detail (grain, veins, micro-roughness, bump) and optional weathering, no UVs needed. Identical specs are shared automatically. Prefer presets over plain colours; real objects mix materials (wooden top + metal legs, ceramic body + cork lid).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wetNo0-1 rain-wet look: darker, glossy, more in low spots.
bumpNoSurface relief multiplier (0 = none).
dirtNo0-1 grime in cavities.
dustNo0-1 dust on top surfaces.
mossNo0-1 moss on damp, shaded, up-facing spots (stone, wood, roofs, ruins).
nameNoMaterial name. Re-using a name updates that material everywhere.
rustNo0-1 rust in crevices, blotches and run-off streaks (iron/steel/painted metal get it automatically from weathering).
snowNo0-1 snow settled on up-facing surfaces.
wearNoFine control 0-1 instead of weathering: edge wear.
alphaNo<1 for see-through (not glass - use the glass presets).
colorNosRGB colour: '#rrggbb', a CSS-like name, or [r,g,b] 0-1. Converted to linear for you.
facesNoOnly these faces (adds a slot), e.g. {side:'top'} for a different tabletop surface.
grainNoWood grain / metal brushing direction. auto = along each object's longest axis (right for boards and legs sharing one material).
reuseNoAssign an existing material by name instead of building one.
color2NoSecondary colour (wood dark grain, marble veins, mortar).
paramsNoRaw Principled BSDF inputs, e.g. {'Coat Weight': 1, 'Sheen Weight': 0.5}.
presetNoPreset name - see list_material_presets (wood_oak, wood_walnut, marble, concrete, fabric, leather, brushed_metal, ceramic, glass, ...). Natural materials use Poly Haven scans by default (see source).plastic
sourceNoauto (default): scanned Poly Haven textures wherever a scan exists (wood, concrete, stone, brick, plaster, fabric, velvet, leather, clay, bark, rust, tread plate...) - downloaded once, real-world size, grain follows each part, color= tints the photo. Procedural only where Poly Haven has no scans (polished/coloured metals, glass, plastics, porcelain, paint) or offline. procedural: never download.auto
objectsYesObject name or list of names.
metallicNo
polyhavenNoAny Poly Haven texture by id or by description, e.g. 'mossy rock', 'green rusty metal', 'red leather', 'herringbone wool' (tiled/jointed scans are skipped unless the words ask for tiles/planks/bricks).
roughnessNo
scratchesNo0-1 fine scratches (glossy metal/plastic/paint get them from weathering).
weatheringNoAge the surface: edge wear on convex edges (painted metal chips to bare metal), grime in crevices and contact areas, dust on up-facing surfaces. 'light'/'used' is right for most real-world objects.
texture_mapsNoImage files {base_color, roughness, metallic, normal, alpha}: box-projected, no UVs needed.
texture_scaleNoPattern size multiplier (2 = features twice as big).
emission_strengthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description must carry the full behavioral load. It usefully discloses that identical specs are shared automatically, no UVs are needed, and reusing a name updates everywhere — real behavioral context. But it omits key mutation semantics: which objects are valid targets, whether it overwrites existing materials, permission/rate concerns, or what happens on name collision vs. reuse.

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?

Three sentences with a coherent arc: capability → sharing behavior → usage preference. But the first sentence is a dense list of material features that reads more like marketing copy than an operational statement, and the description never front-loads what the tool actually does to an object.

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 27-parameter mutation tool with no annotations and no output schema, the description covers material semantics reasonably but leaves essential gaps: it doesn't state the core action (applying to objects), doesn't mention that this is a write/mutating operation, and gives no output/return expectations. It is minimum-viable but not complete.

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

Parameters3/5

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

Schema description coverage is 89%, so the schema carries most parameter meaning and a baseline of 3 applies. The description adds qualitative intent — 'prefer presets over plain colours', material mixing guidance — which is beyond-schema, but the two bare parameters (metallic, roughness, emission_strength) and the interplay of preset/name/reuse/source are not clarified.

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

Purpose3/5

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

The description describes material qualities (PBR, procedural detail, weathering) and gives application guidance, but never states the actual verb+resource of the tool — that it assigns/applies a material to object(s). The parameter 'objects' is the only hint of the action. An agent must infer the core purpose from context rather than reading it directly.

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 offers actionable preferences: 'Prefer presets over plain colours' and 'real objects mix materials' with concrete examples (wooden top + metal legs). However, it never names alternative tools or states when NOT to use this one — notably it doesn't point to add_surface_detail, add_damage, or uv_unwrap, which are close siblings in the same space.

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

Deploy Server

Other Tools