MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_symmetrize_targets

DestructiveIdempotent

Repair asymmetric MakeHuman character modeling targets by copying one side's values onto the other; use direction and dry-run to preview changes before writing.

Instructions

Make a MakeHuman character's modeling targets left/right symmetric, by copying one side's modeling onto the other.

MPFB itself cannot do this. Its symmetry setting only mirrors changes made while it is on and leaves previously set values alone, so a character that has already drifted asymmetric has no repair path in MPFB's UI. Call mpfb_get_target_stack first: its asymmetries field lists which categories differ and by how much.

This is destructive and there is no undo across the socket. It overwrites values the user may have set on purpose. direction is required - "left_to_right" or "right_to_left" - because which half of a face is the good one is not something a tool can guess. Run it with dry_run: true first: the answer lists exactly the changes a real run would make, and writes nothing.

section restricts the operation to one target.json section, so "make the eyes symmetric" does not also flatten deliberate asymmetry in the hands; omit it to cover every section. Only categories with has_left_and_right: true are considered, paired through target.json's opposites table rather than by matching l-/r- name prefixes, which would be a guess.

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; read assets_possibly_stale and call mpfb_refit_human when the modeling is done.

result carries changes - per category, both sides' values before, the value after, and every target file touched, with targets being null rather than [] under dry_run: true, because which files a write would touch is only knowable by doing the write - plus already_symmetric, basemesh_name, and skipped for a category whose target file could not be found, since one unreachable target is reported rather than abandoning the rest of the body.

Under dry_run: true, performed is false even though changes has entries in it: those are the writes that would happen. A subject that cannot be resolved (found: false, subject_not_found) and a basemesh in edit mode or without shape keys (ready: false) are answers, not errors.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`prune`	No
`refit`	No
`dry_run`	No
`section`	No
`direction`	Yes

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?

The description goes far beyond the annotations. While annotations correctly flag it as destructive and not idempotent (ambiguous), the description adds critical context: there is no undo, dry_run produces a preview that writes nothing, prune/refit behavior, how `skipped` is handled (does not abandon the whole operation), and that certain failure conditions are answers, not errors. This is exemplary 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?

The description is dense and well-structured with bolded parameter names and logical paragraph breaks. Every sentence adds value, though it is quite long. It is front-loaded with the core purpose and critical warnings.

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?

Given the tool's complexity (destructive, no undo, multiple parameters, dependent on external state), the description covers all necessary aspects: purpose, prerequisites, parameter semantics, destructive nature, dry-run workflow, and output interpretation. It even references the output schema's fields to explain their meaning.

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?

Schema description coverage is 0%, so the description carries the full burden. It explains why `direction` is required (cannot guess), what `section` restricts, what `prune` and `refit` do, and the effect of `dry_run` on the `targets` output. It compensates completely for the lack of schema descriptions.

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?

The description states a specific verb+resource ('Make a MakeHuman character's modeling targets left/right symmetric') and immediately differentiates itself from MPFB's own symmetry feature and from mpfb_set_targets. It precisely explains the scope (modeling targets) and mechanism (copying one side onto the other).

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 the prerequisite sibling tool (mpfb_get_target_stack) to call first and why (its `asymmetries` field). It directs the agent to use dry_run first and explains when to use `section`. This is a strong example of explicit when/when-not guidance.

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