MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_create_human_from_preset

Build a new Blender character from a saved preset, importing phenotype, rig, garments, skin, and eye materials without altering existing scene objects.

Instructions

Build a new character from a saved MPFB preset: phenotype, modeling targets, rig, body parts, garments, skin and eye materials. It adds a character and changes nothing already in the scene - this is not "load into the current character". Seconds, not milliseconds: it imports and fits every asset the preset names.

preset_name is a name, never a path - mpfb_list_presets reports the ones that exist, and a miss here comes back with available_presets naming them.

Each override defaults to null meaning use what the preset says; overrides in the response reports, per argument, what you asked for, what the preset held and what was used.

override_rig: "NONE" for no rig, or any identifier mpfb_list_rigs reports, custom.* included. A rigify.* preset gives you a meta rig - finish it with mpfb_generate_rigify_rig.
override_skin_type: mpfb_set_skin's five skin_type values, plus "NONE" for no skin at all.
override_clothes_material_type / override_eyes_material_type: mpfb_add_asset's material_type, for garments and every body part but the eyes, and for the eyes.
load_clothes false builds the body and skips the garments.
scale: 0.1 metre (MPFB's default), 1.0 decimetre, 10.0 centimetre.
material_instances_policy: NEVER, ENHANCED or ENHANCEDMS - which skin types get per-region material slots. Defaults to ENHANCED, which is MPFB's preset panel's default rather than the NEVER its service function defaults to; both come back, as material_instances_policy_used and _service_default.

On created: true (and so performed: true), result carries basemesh_name, rig_object_name and rig_identified_as, equipped_assets (kind, name and asset_source per item), skin_material_identified_as, settings_used (MPFB's own settings dict, in MPFB's own key names), objects_created and active_object_after - the selection is not restored, because deserialization activates what it creates and there is no prior state to return to.

Read unresolved_assets. A preset that names a garment or body part which is not installed here loads without it and MPFB says nothing; that field names each one and the subdirectory it was looked for in.

Refusals come back as created: false with a blocked_by: preset_not_found (with available_presets), preset_unreadable, not_object_mode, unknown_material_instances_policy, config_dir_missing, settings_incomplete, and deserialization_failed - the one that is not a no-op, since a character is built in stages, so objects_created names what was left behind. Its commonest cause is a rig the preset names and this Blender lacks: MPFB's rig adders raise rather than degrade, so retry with override_rig.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`scale`	No
`preset_name`	Yes
`load_clothes`	No
`override_rig`	No
`override_skin_type`	No
`material_instances_policy`	No
`override_eyes_material_type`	No
`override_clothes_material_type`	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.9/5.0

Behavior5/5

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

Goes well beyond the annotations: states it adds a character without altering existing scene content, warns execution takes seconds not milliseconds, discloses that the selection is not restored, flags that unresolved_assets silently drops missing assets, and enumerates every blocked_by refusal including the non-atomic deserialization_failed partial-build case.

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?

Long but dense and front-loaded: the core purpose and the 'not load into current character' caveat come first, then a bulleted parameter block, then the result/refusal sections. Nearly every sentence carries actionable information, though the volume of return-value detail edges past what strictly needs to be in the description.

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 an 8-parameter, non-idempotent, potentially partial-failure mutation tool with 0% schema coverage, the definition supplies everything needed: parameter semantics, defaults, valid ranges, silent-failure warnings, refusal taxonomy, and retry guidance. Nothing an agent needs 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 description coverage, the description carries the full burden and delivers: preset_name is a name not a path, all override_* fields default to null meaning 'use the preset', scale units are given (0.1 m default, 1.0 dm, 10.0 cm), and the material_instances_policy default is documented with its divergence from the service default.

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 and resource ('Build a new character from a saved MPFB preset') and enumerates the asset classes it covers (phenotype, targets, rig, garments, skin, eyes). It explicitly differentiates itself from the sibling concept of loading into the current character, so an agent can distinguish it from mpfb_create_human and mpfb_add_asset.

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 names when to use it versus alternatives: mpfb_list_presets for valid names, mpfb_list_rigs for rig identifiers, mpfb_generate_rigify_rig to finish a meta rig, mpfb_set_skin for skin_type values, mpfb_add_asset for material_type values. It also gives a retry path (use override_rig) when deserialization_failed occurs.

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