MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_list_assets

Read-onlyIdempotent

Search installed MakeHuman assets in Blender by subdirectory, name keyword or asset pack. Lists garments, hair, skins and poses without adding them to the scene.

Instructions

Find the MakeHuman assets installed in this Blender - garments, hair, eyes, eyebrows, eyelashes, teeth, tongue, body proxies, skins, poses - narrowed by subdir, by a keyword in the name, and by asset pack. Adds nothing to the scene. The forward counterpart of mpfb_get_object_info, which says what an existing object was made from.

The answer is capped and is usually a subset. Check truncated before concluding an asset is not installed; total_count says how many matched. The first call for a subdir is the slow one: MPFB loads a preview image per asset, once per subdir per Blender session.

Arguments, all optional and combining with AND:

asset_subdir - one of "clothes", "hair", "eyes", "eyebrows", "eyelashes", "teeth", "tongue", "proxymeshes", "skins", "poses", "ink_layers", matched exactly and case-insensitively. Omit it to search every subdir, then read counts_by_asset_subdir to pick a narrower one.
name_contains - case-insensitive substring of the asset's name or label.
pack - substring of an installed pack's name, so "hair03" finds hair03_ccby.
limit (default 200, max 1000) and offset - paging over the matched set, sorted by subdir then name.
refresh - rescan first. Needed only when assets were installed after Blender started; it rescans the whole library and writes MPFB's caches.

result carries:

assets: this page's entries, each with name (filename without extension), label (MPFB's display text), fragment, path, object_type, asset_subdir, file_type, pack, pack_ambiguous and thumb_path.
counts_by_asset_subdir: how many assets each scanned subdir holds, ignoring name_contains, pack and the cap.
requested_asset_subdir/asset_subdir_recognized/ known_asset_subdirs and requested_pack/pack_recognized/ known_packs, so a misspelling is distinguishable from an empty subdir or pack.
asset_roots_searched: per subdir, the directories actually scanned. A configured data root that does not hold that subdir is not searched, which is the usual explanation for "I installed it and it is not listed".
count, total_count, truncated, offset, limit.

How to name an asset when applying it. Pass an entry's path (absolute) or its fragment ("fedora/fedora.mhclo", what MPFB records on the resulting object and what survives a move to another machine) to mpfb_add_asset, together with its object_type. Assets in skins are materials rather than meshes and go to mpfb_set_skin instead. A fragment is not a path; handing one to a file-opening tool fails confusingly. For skins, poses and ink_layers the object_type ("Material", "Pose", "Other") says what the asset is rather than naming an argument.

pack is derived from a directory-name convention, not recorded by MPFB. pack: null is ordinary for a hand-installed asset, and pack_ambiguous: true means two packs claim the name and the reported one is a coin toss. total_count can under-report too: MPFB's cache is keyed by a label derived from the filename alone, so two assets whose filenames differ only in case or underscores collapse into one entry.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`pack`	No
`limit`	No
`offset`	No
`refresh`	No
`asset_subdir`	No
`name_contains`	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 declare it a safe read, so the bar is lower, and the description still discloses rich behavior: results are capped and usually a subset, truncated/total_count flags must be checked, first call per subdir is slow due to preview-image loading, refresh rescans the whole library and writes caches, and cache-keying can collapse entries and under-report totals. This is far beyond the readOnly/idempotent annotations.

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-loaded with a one-line purpose and the capped-answer warning, then a structured argument list and a return-shape section. It is long, but every block is load-bearing for a tool with 6 undocumented parameters and a complex result object. Marginally more verbose than strictly needed but not padded.

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?

Even with an output schema, the description explains how to interpret result fields (truncated, total_count, counts_by_asset_subdir, asset_roots_searched) and the naming model (path vs fragment, object_type). For an asset-listing tool whose correctness depends on paging and cache subtleties, this is complete enough to call and interpret correctly.

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 must compensate and it does: it documents every parameter (asset_subdir enum values, name_contains substring semantics, pack directory-convention derivation, limit default/max, offset, and when refresh is needed) plus how parameters combine (AND). It adds meaning the bare schema completely lacks.

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+resource ('Find the MakeHuman assets installed in this Blender') and enumerates the asset categories. Explicitly distinguishes itself from siblings: it contrasts with mpfb_get_object_info (the reverse direction) and routes skin assets to mpfb_set_skin and application to mpfb_add_asset.

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 clear when-to-use context (before applying an asset, to check what is installed), names the exact sibling tools to use downstream (mpfb_add_asset, mpfb_set_skin), and explains edge cases like 'I installed it and it is not listed'. No alternative is left implicit.

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