MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_list_docs

Read-onlyIdempotent

Find MPFB developer documentation URLs by topic or keyword, covering services, file formats, entities, and UI. Returns raw and rendered links without fetching content.

Instructions

Addresses for MPFB's developer documentation - one document per service (HumanService, TargetService, ...), per file format (.mhclo, .mhmat, .target, the preset and rig JSON) and for its object property store. Use it to answer "how does MPFB actually do X" rather than inferring it from a tool response.

Changes nothing, needs no Blender and no MPFB, and fetches nothing: it returns URLs for the client to retrieve. raw_url returns the markdown; page_url is the rendered page for a person.

Arguments, both optional: topic (general, services, fileformats, entities, ui; exact, case-insensitive) and keyword (case-insensitive substring over path, title, description and keywords). With neither, returns everything it has.

A curated subset, not the tree. curated is always true, tree_document_count says how large the tree it was drawn from is, and tree_url is the full listing - go there when what you need is not here, rather than concluding it does not exist. Pinned to master (ref), so a document may describe a newer MPFB than the installed one.

result carries:

documents: each {path, raw_url, page_url, title, description, keywords, topic}, path being repo-relative (docs/services/humanservice.md). Titles, descriptions and keywords are mpfb-mcp's own text; MPFB publishes no index.
count, curated, curated_document_count, tree_document_count, tree_url, ref, repository.
requested_topic, topic_recognized, known_topics, requested_keyword. An unknown topic matches nothing rather than failing, so check topic_recognized before reading an empty documents as "no such documentation".

Not capped and not paged: under twenty entries, so no truncated or total_count to check.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`topic`	No
`keyword`	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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: it changes nothing, needs no Blender/MPFB, and critically 'fetches nothing' — returning URLs rather than content. It also discloses the curated-subset constraint, the master pinning caveat, and the unknown-topic behavior.

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 purpose and organized with bold labels and a bulleted result listing, so it is scannable despite its length. Each sentence carries information, though the result-field inventory is dense enough to verge on over-long for a list tool.

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?

An output schema exists, yet the description still maps the return fields and, more importantly, documents the two otherwise-undocumented parameters and the topic_recognized pitfall for empty results. Nothing an agent needs to call it correctly 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 carries the full burden and does: it enumerates the exact accepted topic values (general, services, fileformats, entities, ui), their matching semantics (exact, case-insensitive), keyword's substring scope over four fields, and the no-argument fallback. This is richer than the empty schema.

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 resource (MPFB developer documentation addresses) and enumerates exactly what it covers (per service, per file format, object property store), plus a concrete use case ('how does MPFB actually do X'). It is unmistakable against siblings like mpfb_list_urls or mpfb_get_object_info.

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?

Explicitly frames when to reach for it ('rather than inferring it from a tool response') and routes the agent onward when the curated subset is insufficient ('go there when what you need is not here, rather than concluding it does not exist'). No named sibling alternatives, but no real doc-lookup sibling exists to contrast with.

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