MPFB MCP

Official

Overview Schema Source Related Servers Discussions Admin

mpfb_list_urls

Read-onlyIdempotent

Returns official MPFB and MakeHuman community URLs for downloads, asset packs, docs, forum, and issue tracking without fetching them, so clients can retrieve links even when Blender is unreachable.

Instructions

Addresses for the MPFB and MakeHuman community sites: downloading MPFB, asset packs, documentation, forum, issue tracker. Takes no arguments, changes nothing, and fetches nothing - it hands back URLs for the client to retrieve.

Use it rather than composing a makehumancommunity.org address. Reach for it when mpfb_list_assets finds little (URL_ASSET_PACKS) or mpfb_get_status reports the system assets pack missing (URL_SYSTEM_ASSETS). For MPFB's developer documentation, one document per service and file format, use mpfb_list_docs instead.

It answers even when MPFB or Blender is unreachable, which is when these links matter most - so check source_of_truth before quoting a URL: "mpfb" was read from the running MPFB, "builtin_fallback" is mpfb-mcp's vendored copy with fallback_reason saying why. Neither is an error.

result carries:

urls: every link, each {key, url, title, description, keywords, source}. key is MPFB's own constant name (URL_ASSET_PACKS). source is "mpfb" for one of MPFB's constants, "mpfb_mcp" for an ecosystem link this package adds (MakeHuman itself, the community asset repository). title, description and keywords are mpfb-mcp's text rather than MPFB's, and are null for a constant MPFB has added since.
source_of_truth, fallback_reason, blender_reachable, and mpfb_status (state: ok, absent, not_initialized or unreachable; plus package, version, weburls_module, weburls_read).
fallback_stale and fallback_differences: whether the vendored copy disagrees with the running MPFB, and per key how (changed, added_by_mpfb, missing_from_mpfb). Both null when there was nothing live to compare against, which is not agreement.
count, vendored_mpfb_key_count, skipped_keys.

Not capped and not paged: around twenty entries, all of them, every call. No truncated or total_count to check.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

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.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds non-obvious behavior: it fetches nothing itself, it still answers when MPFB or Blender is unreachable, source_of_truth/fallback_reason semantics are explained, and neither fallback is an error. It also states there is no pagination or truncation. This is rich context beyond the 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?

Well front-loaded (purpose, then when-to-use, then fallback behavior, then result shape) with bullets that aid scanning. However, the long 'result carries' section restates much of what the output schema already provides, so it is somewhat heavier than needed for a no-arg 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?

For a trivial no-arg read tool with a full output schema and clear annotations, the description covers usage, fallback/edge-case behavior, and result contents. Nothing an agent needs in order to call it or interpret the response is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the baseline is 4. The description's field-level detail is about the return payload rather than input semantics, so nothing here lowers the score; there are simply no parameters to clarify.

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: it hands back addresses for the MPFB/MakeHuman community sites, enumerates what those links cover (downloads, asset packs, docs, forum, issues), and immediately distinguishes itself from the sibling list tools. An agent can tell it apart from mpfb_list_docs and mpfb_list_assets without opening any schema.

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?

Explicit when-to-use (rather than composing a makehumancommunity.org address; when mpfb_list_assets comes up short or mpfb_get_status reports the system assets pack missing), plus a named alternative (mpfb_list_docs) for the developer-docs case. Both routing conditions and the exclusion are stated, not implied.

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