MPFB MCP

Official

by makehumancommunity

Overview Schema Source Related Servers Discussions Admin

Python

Local

mpfb_get_object_info

Read-onlyIdempotent

Find what MakeHuman asset a Blender object came from and what belongs with it, without changing or selecting anything.

Instructions

Identify one Blender object, say what MakeHuman asset it was made from, and list what else belongs with it. Changes nothing, selects nothing.

name is a Blender object name, typically one from mpfb_list_objects. Omit it to ask about the currently active object - what the user just created or clicked. Not resolving a subject is a normal answer: found is false and message says whether no such object exists or nothing is active.

result always carries found, subject_resolved_by ("name" or "active") and message. When found is true it also carries:

name: the resolved object's name. Carry this forward rather than re-deriving from the active object, which changes as the user clicks.
in_current_scene: object names are unique across the whole .blend, so a name can resolve to an object mpfb_list_objects does not list. False here is not a contradiction between the two tools.
object_type (MPFB's type, or null for a plain Blender object), blender_type, is_makehuman_object.
rigify_role: "generated_rig", "metarig", or null - reported whatever the object's type, because MPFB tags the rig it generates through Rigify as a Skeleton.
asset_info: what the object was made from, or null when it has no MPFB type. Its keys depend on the object type - a skeleton has no mhclo, so it has no mhclo_path key rather than a null one. Skeleton/Subrig carry rig_identified_as and rig_definition_path; a mesh asset (Clothes, Eyes, Hair, Proxymeshes, ...) carries asset_source, mhclo_path, material_identified_as, material_source and mhmat_path; a Basemesh carries the last three. An unrecognized MakeHuman type gets an empty dict.
related_objects: the MakeHuman objects among this one's parents, children and siblings - "what belongs with this character" - each with the same fields plus its own asset_info, excluding the subject. A flat list, not a tree; call this tool again on a name to walk the structure.
other_related_objects: relatives carrying no MPFB type, each with a rigify_role. This is where a Rigify rig built outside MPFB shows up: it drives the character but appears in no other list this server returns.

Reading asset_info correctly: every *_path is an absolute path or null, while the *_source fields beside them are MPFB's short fragments and are not paths. The pair keeps two situations apart - a null fragment means nothing was recorded, a fragment with a null path means the asset is recorded but is not installed under any asset root this Blender can see. A null material_source on a mesh asset is ordinary: the object uses the default material named inside its mhclo, deliberately not resolved here. The *_identified_as values are read off the object as it is now, while the *_source fragments record what was loaded and are never rewritten when the object is edited by hand; where they disagree, the identified value describes reality. And mhclo_path may point at a .proxy file, so do not decide what something is from the suffix.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description reinforces it with 'changes nothing, selects nothing.' Beyond that it discloses real behavioral nuance - that `found: false` is a normal outcome, that the active object shifts as the user clicks, and that a resolved name may not appear in mpfb_list_objects.

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?

It is well front-loaded and bullet-structured, but it is very long and a large fraction of it documents `result`/`asset_info` field semantics that the existing output schema already covers, so several sentences do not earn their place in a tool description.

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 single optional parameter, an output schema, and rich annotations, the description is more than complete - it covers calling modes, resolution failure, and edge cases (null fragment vs null path, .proxy suffix) with nothing an agent would need left out.

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?

The single parameter has 0% schema coverage, and the description fully compensates: `name` is defined as a Blender object name, its default/omitted behavior is spelled out, and the consequence of not resolving a subject is explained.

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 opening states a precise verb+resource: identify one Blender object, name its MakeHuman source asset, and list related objects, plus the explicit non-effects ('Changes nothing, selects nothing'). It also anchors itself against the sibling mpfb_list_objects as the source of valid names.

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?

It clearly explains the two calling modes (pass `name`, or omit it to inspect the active object) and how to obtain names from mpfb_list_objects. It even recommends re-calling to walk the hierarchy, but it never states when to prefer this over the sibling mpfb_get_character_summary.

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