Skip to main content
Glama

mpfb_remove_asset

Destructive

Removes a garment, body part, or body proxy from a MakeHuman character in Blender, cleaning up mask modifiers and sub-rigs so the character has no leftover holes or orphaned data.

Instructions

Take one mesh asset - a garment, a body part or the body proxy - off a MakeHuman character and clean up after it, the way MPFB's own "unload" does.

Use this rather than deleting the object. MPFB hides the body under a garment with a mask modifier on the basemesh (and on the body proxy, for garments), and a garment may have brought a sub-rig of its own. Deleting the object with a generic Blender tool leaves both behind, and the character keeps a hole in it with nothing visible to explain it.

name is required and is the asset object's own Blender name, as mpfb_list_objects reports it or as mpfb_add_asset returned it in asset_object_name. There is no active-object fallback: this deletes an object. Equipping two copies of one asset gives ...hat and ...hat.001, so check which you are naming. This is not undoable across the socket: the object and its mesh data are gone when the call returns.

On removed: true, result carries asset_object_name, object_type and asset_source - all read before the deletion - plus basemesh_name, objects_removed naming everything the call deleted, mask_modifiers_removed naming the objects and modifiers that went, subrig_removed, and two things MPFB leaves behind and never mentions: vertex_groups_left_behind (the Delete.<name> groups themselves; only the modifiers referencing them are removed) and mesh_data_orphaned (the mesh datablock, which keeps no users until the file is saved and reloaded). Both are harmless and both are invisible unless reported.

Refusals come back as removed: false (and so performed: false) with a blocked_by and a sentence: subject_not_found, basemesh_not_found, not_object_mode, asset_source_missing - without it the mask modifier cannot be identified and removal would be silently partial - and not_a_mesh_asset, which refuses a basemesh or a skeleton outright, because the underlying MPFB function would happily delete either.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes

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 already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the destructive nature is known. The description goes far beyond by detailing exactly what is destroyed (object, mesh data), what is left behind (vertex groups, orphaned mesh data), the no-undo-across-socket warning, and the refusal conditions. This is rich behavioral context that greatly assists correct invocation.

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 well-structured with clear sections (usage, parameter, return, refusals) and front-loads the key point. However, it is somewhat lengthy and could be trimmed slightly, but every sentence earns its place by providing crucial behavioral or parameter details.

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 destructive operation with a single parameter and rich output schema, the description covers all necessary aspects: purpose, alternatives, parameter semantics, return values (even though output schema exists, it explains the fields' provenance), failure modes, and side effects. It is complete for an agent to call correctly and interpret results.

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% (no description for the 'name' parameter in schema), so the description must compensate. It does: it explains that 'name' is the asset object's own Blender name, gives examples from mpfb_list_objects and mpfb_add_asset, warns about duplicate naming (hat vs. hat.001), and emphasizes it's required with no fallback. This adds significant meaning beyond the schema's bare type. A minor deduction because the description doesn't specify the exact format for names when duplicates exist (e.g., whether to use the exact name with suffix), but the guidance is strong.

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?

Specific verb+resource: removing a mesh asset (garment, body part, or body proxy) from a MakeHuman character with proper cleanup. The description explicitly differentiates from generic deletion and implicitly from the sibling mpfb_add_asset (its counterpart), so an agent can distinguish it without opening the 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?

Explicitly states when to use this tool rather than deleting the object, and explains why (mask modifiers, sub-rigs, character holes). It also mentions the refusals that indicate when the tool won't work (subject_not_found, not_a_mesh_asset, etc.), providing thorough usage context.

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