MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_list_targets

Read-onlyIdempotent

List available MakeHuman modeling targets in Blender and report the exact shapekey_name needed to set each morph, without changing anything.

Instructions

Find the MakeHuman modeling targets available in this Blender - the named morphs like nose-scale-depth-incr that shape a character - and report each under the name that setting it will require. Changes nothing.

The phenotype (gender, age, weight, muscle, height, proportions) is not here: they are attributes on the basemesh rather than target files, and are mpfb_get_macro_details / mpfb_set_macro_details territory.

The answer is capped. Check truncated before concluding a target does not exist; total_count says how many matched.

Arguments, all optional: section (a section name from target.json or synthesized from a user target directory, matched exactly and case-insensitively; omit it for the overview), name_contains (case-insensitive substring, applied to category and target names alike), and limit (default 200, max 1000) with offset, which page over a section's categories when it has them and over user_targets otherwise.

result carries:

sections: every section, each {name, label, source, category_count, target_count}. Around thirty entries, always present. source is "system", "user", or "both" when a user directory shares a bundled section's name - common, and MPFB merges the two, so such a section returns both.
categories: present when section named one with bundled categories, each {name, label, has_left_and_right, targets, opposites} from target.json. These are what mpfb_set_targets' modifiers entries address, and opposites is the decr/incr and left/right pairing behind MPFB's sliders. null when no section was asked for, or the one asked for is only a user directory.
user_targets: what the user data directories hold, filtered to section when one was given, each with name, shapekey_name, path and listed_in_mpfb_ui.
target_json_path/target_json_exists and system_targets_dir: the bundled index is ~140 KB of JSON and is not returned here - a client that can read the Blender host's filesystem should parse it directly instead.
unindexed_system_target_dirs: bundled target directories with no target.json section, each with a count. The index reads as the complete list of bundled targets and is not.
user_target_dirs: the directories actually scanned, so a target that did not appear can be looked for where it was expected.
requested_section/section_recognized/known_sections, count, total_count, truncated, offset, limit.

How to name a target when setting it. Use shapekey_name, never name. name is the filename with its extension stripped, for display; shapekey_name is what MPFB calls the shape key and the only string it accepts. The two are equal for most targets and not above 60 characters, where MPFB encodes the name - and a caller using name there addresses nothing at all, silently. Inside a category, targets and opposites are already in that form.

Two differences from MPFB's own modeling panels, both real rather than bugs here: this tool scans per call, so it reports a target installed since Blender started, which the panels cannot show until it restarts; and listed_in_mpfb_ui: false marks a *.target.gz outside the custom section, loadable but skipped by MPFB's own scan.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`section`	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.7/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: results are capped ('check truncated'), total_count semantics, per-call scanning that sees targets installed since Blender started, and the meaning of listed_in_mpfb_ui:false. These are real operational traits an agent could not infer from 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 the core purpose and the naming rule, and most sentences carry operational weight. However, the lengthy enumeration of result fields is partly redundant given an output schema exists, so it is longer than strictly necessary even though it is well-organized.

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 four-param read tool with an output schema and full annotations, the description covers everything an agent needs: what it returns, the truncation trap, the critical name-vs-shapekey_name rule (including the >60-char silent-failure case), and the unindexed-directory caveat. Nothing material is missing.

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%, so the description must carry the load and it does: section (exact, case-insensitive match against target.json or synthesized user dir; omit for overview), name_contains (substring applied to category and target names alike), limit (default 200, max 1000) and offset (paging over categories or user_targets). All four undocumented params are fully 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?

States a specific verb and resource ('Find the MakeHuman modeling targets available in this Blender') and further scopes it ('named morphs like nose-scale-depth-incr that shape a character'). It explicitly excludes the phenotype attributes and routes them to mpfb_get_macro_details / mpfb_set_macro_details, so the agent can distinguish it from siblings without opening schemas.

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?

Gives a clear when-to-use framing plus an explicit exclusion ('the phenotype ... is not here') and names the alternative tools for that case, and notes the relationship to mpfb_set_targets' modifiers entries. It stops short of contrasting with mpfb_get_target_stack (applied targets) or listing prerequisites, so not fully exhaustive.

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