MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_generate_rigify_rig

Destructive

Convert a character's Rigify meta rig into a poseable generated rig, re-parenting and weighting whatever meshes are attached. Attach garments first; generation is not undoable.

Instructions

Turn a character's Rigify meta rig into a generated, poseable Rigify rig - the second step of the two mpfb_add_rig starts when given a rigify.* identifier.

Attach the character's garments and other mesh assets before calling this. Generation re-parents and re-weights whatever is on the character at the moment it runs, and nothing handles an asset added afterwards. mesh_assets_present reports what was there.

Unlike the other character tools, name resolves to the meta rig rather than to the basemesh, and metarig_name says which armature was used. generated_rig_name is a basename, not the final object name: omit it for MPFB's own fallback, which derives a unique name from the meta rig's, and read rig_object_name for what it became.

meta_rig_action (default "hide", MPFB's own) is what becomes of the meta rig afterwards: "keep" leaves it visible, "hide" keeps it in the scene but out of viewport and renders, "delete" removes it. Prefer "hide". Deleting the meta rig makes the character permanently unrefittable: mpfb_refit_human can only refit a generated Rigify rig through its meta rig, and with none in the scene it refits the mesh assets, leaves the rig behind and says nothing. refit_will_be_possible reports this either way.

This tool is not undoable and cannot restore your selection. Generation's own last act is to select and activate the rig it made, so active_object_after reports what is active now instead.

On generated: true, result carries rig_object_name, metarig_name, metarig_disposition (kept/hidden/deleted), refit_will_be_possible, mesh_assets_present and active_object_after.

generated: false does not mean nothing happened, though performed follows it. When Rigify judges the meta rig invalid it returns after MPFB has already deselected everything, activated the meta rig and possibly renamed it or run Rigify's face upgrade; that case reports metarig_renamed and metarig_name_after beside the refusal. Other refusals carry a blocked_by: subject_not_found, no_armature_found, not_a_metarig (rigged, but not with a Rigify meta rig), already_generated (generation moved this character onto its generated rig, so its meta rig is no longer among its relatives), rigify_unavailable and not_object_mode.

Input Schema

TableJSON Schema

Name	Required	Default
`name`	No
`meta_rig_action`	No	hide
`generated_rig_name`	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?

Annotations already flag destructive/non-idempotent, and the description adds substantial context beyond them: it is not undoable, cannot restore selection, re-parents and re-weights existing assets, and deleting the meta rig makes the character permanently unrefittable. It also warns that 'generated: false does not mean nothing happened' and enumerates blocked_by refusal reasons.

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?

Front-loads the core action, then prerequisites, parameter semantics, return shape and failure modes in a logical order. It is long and somewhat dense with bolded clauses, but given the destructive, non-undoable nature and zero schema coverage, nearly every sentence earns its place.

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?

Complete for a destructive, non-undoable tool: it covers prerequisites, parameter resolution quirks, meta-rig disposition, post-conditions, and the full set of failure reasons. The output schema exists, yet the description still names key result fields, which is redundant but not harmful.

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 does so: it clarifies that name resolves to the meta rig (not basemesh), that generated_rig_name is a basename with an MPFB fallback when omitted, and that meta_rig_action accepts keep/hide/delete with default 'hide' and distinct scene effects.

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 precise verb and resource: turning a character's Rigify meta rig into a generated, poseable Rigify rig. It explicitly positions itself against the sibling that precedes it ('the second step of the two mpfb_add_rig starts'), so an agent can tell the two apart without opening either schema.

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?

Gives an explicit precondition ('Attach the character's garments and other mesh assets before calling this') and explains the consequence of ignoring it. It also names the related sibling mpfb_refit_human and the condition under which this tool's action breaks it, and recommends a default ('Prefer "hide"').

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