MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_set_material_settings

Idempotent

Set a MakeHuman character's eye, skin, hair, and garment material settings in one all-or-nothing batch that survives preset save and reuse.

Instructions

Change a MakeHuman character's procedural material settings - iris colours, the LAYERED skin, the tint of hair and garments - as one all-or-nothing batch that survives mpfb_save_preset and mpfb_create_human_from_preset. Take section, group and socket names from mpfb_get_material_settings.

eyes: {socket, value | color}
skin: {group, socket, value | color}, group as the read keys it
color_adjustments: {object_name, socket, value | color}

Exactly one of value (a float socket) and color (a colour socket). A color is four scene-linear RGBA numbers, like the read's settings, not sRGB: a colour picked by eye comes out too light unless converted.

Nothing is written unless every entry resolves; resolution_errors gives each failure's reason: section not applicable, unknown group or socket (with closest), wrong key for the socket's kind, a float outside its range, or a linked socket, which a write cannot change. Most layered region colours are linked from the color group, and write_instead names the socket to set.

On the layered skin, color's SkinColor shows fully with no diffuse texture and over one only as far as SkinOverride raises it; each region colour has its own *Override. A colour adjustment mixes Color1 with the texture by Factor, so a low Factor is flat colour without texture detail.

mpfb_set_skin, mpfb_set_asset_material and re-adding the eyes rebuild a material from MPFB's defaults, discarding these settings.

result's changes lists each socket in request order with previous_value/new_value and previous_srgb_hex/new_srgb_hex; materials_written names other objects sharing a written material, which changed too.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`eyes`	No
`name`	No
`skin`	No
`color_adjustments`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description goes well beyond that with all-or-nothing atomicity ('Nothing is written unless every entry resolves'), the scene-linear RGBA vs sRGB color gotcha, the fact that linked sockets are unwritable and how write_instead names a substitute, and the cross-object side effect via materials_written.

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 verb and scope, then uses bullets for the three section shapes and bolded callouts for the atomicity and color-space rules. Dense and long, but nearly every sentence conveys a constraint an agent needs; the layered-skin paragraph is the only portion bordering on overload.

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 rich side effects, it covers atomicity, color encoding, resolution failure modes, linked sockets, and cross-object material sharing. An output schema exists (so return values are not strictly required), yet the description's result/materials_written explanation still adds useful behavioral context.

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 description coverage is 0%, so the description must carry the burden, and it does define the entry shapes for eyes, skin, and color_adjustments ({socket|group|object_name, value|color}) plus the value-vs-color mutual exclusion. The 'name' parameter is never explained in either schema or description, leaving one gap.

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 (change) plus the exact resource (MakeHuman character's procedural material settings) and enumerates the affected areas (iris colours, layered skin, hair/garment tint). It also distinguishes itself from siblings by naming mpfb_set_skin and mpfb_set_asset_material as the tools that would overwrite these values.

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

Usage Guidelines4/5

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

Tells the agent to source section/group/socket names from mpfb_get_material_settings and warns that re-adding eyes or calling mpfb_set_skin/mpfb_set_asset_material discards these settings, which is clear routing context. It stops short of an explicit 'use this instead of X when Y' rule, but the prerequisite read and the destruction warning give strong guidance.

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