Skip to main content
Glama

mpfb_add_rig

Destructive

Attach a standard, Rigify or custom rig to an existing MakeHuman character. Rig before dressing, since garments only receive a rig if one is present when attached.

Instructions

Attach a rig to an existing MakeHuman character - MPFB's "Add standard rig" / "Add rigify rig" / "Add custom rig".

Rig the character before dressing it. MPFB rigs a garment only if a rig is present when the garment is attached, and nothing rigs it retroactively. This tool does not refuse to rig a dressed character - decorative garments are legitimate - but mesh_assets_not_rigged names every asset it just failed to rig, and a non-empty list is a mistake unless you meant it.

identifier is exactly what mpfb_list_rigs reports in its identifier field, never the name beside it and never a filename: "default_no_toes" for a standard rig, "rigify.human" for a Rigify one, "custom.my_rig" for a user one. The prefix selects which of MPFB's two non-interchangeable adding functions runs, and add_function_used says which was taken.

import_weights (default true, MPFB's own) loads the vertex weights and adds the armature modifier. With it false the mesh is parented to the armature but not deformed by it.

A rigify.* identifier produces a meta rig, not a finished rig. is_metarig: true comes back with a next_step: attach the garments first, then call mpfb_generate_rigify_rig. A meta rig deforms nothing on its own.

On added: true, result carries rig_object_name - read off the created object, since Blender uniquifies a name already in use, and the address other tools need for the rig - plus basemesh_name, add_function_used, family, is_metarig/next_step, weights_loaded with weights_from and weights_path (MPFB resolves weights through a fallback table, so a rig legitimately borrowing another's is normal and weights_loaded: false is not), armature_modifier_added, basemesh_location_before with basemesh_moved_to_origin and rig_location - both adding functions move the basemesh to the origin and give the armature its old location, which visibly moves a character standing anywhere else - and mesh_assets_not_rigged / subrigs_not_rigged.

Refusals come back as added: false (and so performed: false) with a blocked_by and a sentence: subject_not_found, unknown_identifier (with known_identifiers for the family you addressed), rigify_unavailable, not_object_mode, and already_rigged - MPFB cannot swap a rig, so an existing one has to be deleted first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
identifierNo
import_weightsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and non-idempotent, and the description richly extends this: basemesh is moved to origin, rig cannot be swapped (already_rigged), refusals surface as added:false with blocked_by codes, weights resolution via fallback table. Goes well beyond what annotations alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and prerequisite, which is good, but the body digresses into a full enumeration of result fields (weights_from/weights_path, basemesh_location_before, etc.) that belong to the output schema. Dense but partially redundant with structured data.

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 a stateful mutation tool with an output schema present, the description still supplies the non-obvious behavioral contract: metarig semantics, origin relocation side effect, refusal taxonomy, and non-swappable rigs. Comprehensive for the agent's decision needs.

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 coverage is 0% and there are three parameters, so the description carries the full burden. It precisely defines 'identifier' format and its prefix-selection semantics, and explains import_weights' effect (weights+modifier vs. parenting only) - substantially more than the schema provides.

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 ('Attach a rig to an existing MakeHuman character') and immediately clarifies it maps to MPFB's three adding operations. Distinguishes itself from siblings like mpfb_generate_rigify_rig by explaining the metarig handoff.

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?

Explicit prerequisite ordering ('Rig the character before dressing it'), explains the consequence of violating it (mesh_assets_not_rigged), and names the follow-up tool (mpfb_generate_rigify_rig) for the rigify case. Also names sibling mpfb_list_rigs as the source of valid identifiers.

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