MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_set_targets

DestructiveIdempotent

Set a MakeHuman character's modeling targets in Blender — category modifiers or raw shape keys — in one batch call. All entries must resolve or no changes are applied.

Instructions

Change a MakeHuman character's modeling targets - one modifier (a per-category slider), one raw target, or fifty of them in one call.

Send the whole change as one call. A round trip costs about half a second and the work inside costs milliseconds.

modifiers is the level to use normally. Each entry is {section, category, value, side}, naming a target.json section and one of its categories exactly as mpfb_list_targets reports them:

value runs -1.0..+1.0 for a category that has opposites - the sign picks which of the opposing pair is loaded, and the other is driven to zero - and 0.0..1.0 for one that does not.
side is "left", "right" or "unsided". Required for a category with has_left_and_right: true, and omitted or "unsided" for one without.

targets is the escape hatch, for a user-installed target that belongs to no category. Each entry is {shapekey_name, value} with value in 0.0..1.0, the range Blender clamps a shape key to. Use the shapekey_name mpfb_list_targets reports, not the filename: above 60 characters MPFB encodes the name, and a filename then addresses nothing at all, silently.

Both lists are optional and either may be empty; a call naming neither does nothing and says so.

Nothing is applied unless everything resolves. Every entry is checked inside Blender first - the section and category exist, the side fits the category, the value is in that category's range, the target file can be found - and if any entry fails, resolution_errors names which and zero changes are made. Fix them and resend the whole batch; known_sections and known_categories_in_section come back with the error.

symmetry (default false, MPFB's own) also applies a sided change to the other side, so one entry touches up to four shape keys. prune (default true, MPFB's own) deletes a target's shape key once its value reaches zero. refit (default false, MPFB's own) re-fits the mesh assets and the rig afterwards; leave it false, read assets_possibly_stale, and call mpfb_refit_human once when the modeling is done.

result carries changes - one entry per requested change, in request order, each listing every target file touched with present_before, previous_value, new_value, loaded_from (set when the target was read off disk on this call) and pruned - plus shapekeys_added and shapekeys_removed, refit_performed, assets_possibly_stale and basemesh_name. An unresolvable subject answers found: false with blocked_by: "subject_not_found", and a basemesh in edit mode or without shape keys ready: false with blocked_by. performed is false whenever changes is empty, the all-or-nothing resolution failure included.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`prune`	No
`refit`	No
`targets`	No
`symmetry`	No
`modifiers`	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.8/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds substantial context beyond them: all-or-nothing resolution ('Nothing is applied unless everything resolves... zero changes are made'), that prune deletes a shape key at zero, that symmetry can touch up to four shape keys, and the silent-failure trap when a filename over 60 chars is used instead of shapekey_name. This is genuine behavioral disclosure.

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 front-loaded with the core distinction and organized with bold leads and bullets so key rules are scannable. Most content earns its place given the complexity, though the output-shape paragraph could be trimmed since an output schema exists.

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 batch mutation tool with 0% schema coverage and opaque nested params, the description supplies the entry shapes, ranges, side rules, failure semantics, default behaviors (symmetry/prune/refit), and the shapekey_name-vs-filename trap. Only the undocumented 'name' parameter keeps it from being airtight, but the coverage is otherwise thorough.

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 coverage is 0% and nested objects are opaque (additionalProperties: true), so the description carries the full burden and does so well: it defines modifiers entries as {section, category, value, side} with value ranges (-1.0..+1.0 with opposites, 0.0..1.0 without) and side requirements, and targets entries as {shapekey_name, value} in 0.0..1.0. The one gap is the top-level 'name' parameter, which is never explained.

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 ('Change a MakeHuman character's modeling targets') and immediately distinguishes two operating modes (modifiers vs targets) with different roles. It names the sibling mpfb_list_targets as the source of section/category/shapekey_name values, so an agent can tell this apart from the listing tools.

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 says which mode to use normally ('modifiers is the level to use normally') and when to reach for the alternative ('targets is the escape hatch, for a user-installed target that belongs to no category'). It also gives conditional guidance on refit ('leave it false, read assets_possibly_stale, and call mpfb_refit_human once when the modeling is done') and on batching ('Send the whole change as one call').

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