MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_list_presets

Read-onlyIdempotent

List saved character presets in MPFB's config directory, returning the names accepted by the preset save and create tools, plus paths, sizes and existence.

Instructions

List the character presets saved in MPFB's user config directory - MPFB's "save files", the same ones its own preset panel offers. Each entry's name is what mpfb_save_preset and mpfb_create_human_from_preset take; neither accepts a path.

Not capped and not paged, unlike the other listing tools: a preset collection is tens of files. No preset is parsed, so this says nothing about what is in one; mpfb_create_human_from_preset reports that for the one it loads.

refresh=true rescans the directory through MPFB. MPFB caches the list for the Blender session and rebuilds it only when a preset is saved, so one written by hand, by another Blender or by an earlier session is missing until then - but you do not need to pass refresh to find that out: missing_from_mpfb_list already names any preset file the cache does not hold, because this tool lists the directory itself as well.

result carries:

presets: per preset name, path, size_bytes, modified (ISO 8601 with a UTC offset) and exists. size_bytes and modified come from os.stat here, not from MPFB, which records neither. exists: false means MPFB's cached list still names a preset whose file has been deleted.
Per preset, addressable and not_addressable_reason. MPFB's own panel accepts names these tools will not - anything that could become a path - so a preset saved by hand can be listed here and refused by the other two. Rare, and worth seeing here rather than in a refusal.
config_dir and config_dir_exists: the directory that was scanned, reported whether or not anything was found, so an empty list is an answer rather than an ambiguity.
count, files_in_config_dir, missing_from_mpfb_list, refreshed, listing_failed (a sentence when MPFB could not read the directory at all) and message.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`refresh`	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 cover read-only/idempotent safety, and the description goes well beyond them: the listing is uncapped and unpaged, no preset is parsed, MPFB caches the list per Blender session, refresh forces a rescan, and exists:false signals a cached entry whose file is gone. It also warns that hand-saved names can be listed here but refused by the two consuming tools.

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 and scannable, with the primary purpose and refresh rule up top. The bulleted enumeration of result fields is largely redundant given an output schema exists, though parts of it (size_bytes/modified come from os.stat, not MPFB) add genuine semantics.

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 single-boolean, read-only listing tool this leaves nothing an agent needs unresolved: it explains scope, handle semantics, cache/refresh behavior, failure signaling (listing_failed), and empty-result disambiguation via config_dir_exists.

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% (refresh has no description in the schema), so the description carries the full burden and does: refresh=true rescans the directory through MPFB rather than reading the cache, plus when it is and is not necessary. That is more meaning than a single boolean's schema could convey.

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 ('List the character presets saved in MPFB's user config directory') and disambiguates scope by noting these are MPFB's 'save files', the same set its own preset panel offers. It also distinguishes itself from the surrounding list_* siblings by being uncapped and unpaged.

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?

Names the downstream consumers explicitly (mpfb_save_preset, mpfb_create_human_from_preset) and clarifies neither takes a path, so the returned name is the usable handle. It then gives a conditional rule for refresh ('the cache is rebuilt only when a preset is saved... but you do not need to pass refresh to find that out'), which is exactly the when/when-not guidance an agent needs.

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