MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_apply_expressions

DestructiveIdempotent

Apply saved MakeHuman expressions to a character through MPFB's expression stack, using merge or replace mode to add, update, remove, or clear weighted rows so they persist in presets.

Instructions

Put a MakeHuman character into saved expressions, through MPFB's applied-expressions stack - the mechanism its expressions-library panel and presets use, so the result survives mpfb_save_preset.

expressions is a list of {fragment, weight}: fragment as mpfb_list_expressions reports it, weight in 0.0-1.0. Weight 0.0 removes that expression. mode is "merge" (default: add or update these rows, keep the rest) or "replace" (the stack becomes exactly these rows) - replace with an empty list takes every expression off. Weights from several rows add up per face unit and are clamped at 1.0.

Nothing is written unless every fragment resolves; the refusal (blocked_by: "unresolved_fragments") names the misses and the closest existing fragments. It also refuses without the faceunits01 pack.

The face is rebuilt from the stack, so units composed on top of it with mpfb_set_face_units are discarded and named in discarded_face_units - call mpfb_save_expression first to keep them. refit (default true, as MPFB's library panel) refits the mesh assets and the rig.

result carries changed (the stack or the face moved), requested (per row: action of added / updated / removed / unchanged / absent, and resolved_path), the resulting stack and face as mpfb_get_expression reports them (applied_expressions, aggregate, clamped_face_units, matches_stack), stack_before, removed_by_replace and panel_synced (MPFB's library sliders updated).

Input Schema

TableJSON Schema

Name	Required	Default
`mode`	No	merge
`name`	No
`refit`	No
`expressions`	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.3/5.0

Behavior5/5

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

Far exceeds the annotations (readOnly=false, destructive=true, idempotent=true). It discloses atomicity ('Nothing is written unless every fragment resolves'), the refusal shape (blocked_by: unresolved_fragments), a pack prerequisite (faceunits01), the destructive consequence that face units composed via mpfb_set_face_units are discarded, and clamping behavior. This tells the agent exactly what gets destroyed and when it will refuse.

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?

Dense but well-organized into paragraphs covering semantics, refusals, destructive effects, and return fields, with bolded emphasis on the sharp edges (weight 0.0 removes, replace with empty list clears all). It is long, but the length is justified by the tool's complexity and the missing schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complicated mutating tool with an output schema, the description still adds useful return-value detail (changed, requested actions, applied_applied_expressions, discarded_face_units, panel_synced) and full failure-mode coverage. The only incompleteness is the undocumented 'name' parameter and the lack of an explicit alternative-tool comparison.

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 0% with 4 params, so the description must carry the burden. It richly documents expressions ({fragment, weight}, 0.0-1.0, weight 0.0 removes), mode (merge vs replace, empty-list semantics), and refit, but the 'name' parameter is never mentioned anywhere, leaving one param fully unexplained — a real gap against 0% coverage.

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 ('Put a MakeHuman character into saved expressions') and names the exact mechanism (MPFB's applied-expressions stack). It distinguishes itself from siblings like mpfb_set_face_units and mpfb_list_expressions by describing the stack-based route and that the result survives mpfb_save_preset.

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?

Gives clear context for use and a critical ordering prerequisite ('call mpfb_save_expression first to keep them' before face units are discarded). It references mpfb_list_expressions for fragment format and mpfb_save_preset for durability, but stops short of explicitly stating when to prefer this over the sibling face-unit tools.

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