The PicoBerry MCP Server lets you generate game-ready 3D models, images, and animations from any MCP client (Claude Code, Cursor, Claude Desktop, Cline) using PicoBerry credits — no separate subscription required.
Discovery & Account
list_models – Browse available engines and credit costs by category (3D, image, remesh, texture, animate)
list_animation_presets – Discover engine-specific animation preset IDs (Tripo, Meshy) with optional keyword filtering
get_credits – Check current credit balance and plan details
Generation
generate_image – Create 2D images from text prompts with optional reference image URLs and aspect ratio control
generate_3d_from_text – Turn a text prompt into a game-ready GLB model with optional texture and polycount settings
generate_3d_from_image – Convert a single image (URL or local file path) into a 3D GLB model
Post-Processing
remesh – Retopologize an existing 3D asset to a new polycount
texture – Re-texture an existing 3D asset with PBR materials using a text prompt
animate – Auto-rig and animate a 3D character asset using animation presets
Asset Management
get_asset – Retrieve status and result URLs (model, image, thumbnail) for any asset
wait_for_asset – Poll until an asset completes or times out (configurable interval)
list_my_assets – Browse previously generated assets with filtering by category or keyword
download_asset – Export completed assets as GLB, FBX, or OBJ (with optional Unity texture preset)
It can also be used alongside Blender MCP — generate assets with PicoBerry, then import directly into Blender.
Allows generating 3D models with PicoBerry and importing them into Blender in one workflow.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PicoBerry MCP Server generate a low-poly treasure chest"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Generate 3D models, images, and animations for game and 3D workflows from any
MCP client — Claude Code, Cursor, Claude Desktop, Cline — with no HTTP glue. A thin
wrapper over the PicoBerry /v1 API, so you get PicoBerry's
multi-engine pipeline directly inside your agent. Several 3D and image engines
sit behind one API; call list_models for the live set and each engine's cost.
Generated assets are drafts — useful for prototyping and iteration, and can be
reviewed or refined for your project.
📖 Full reference: API + MCP docs · PicoBerry API
There's no separate subscription for the MCP or the API. Generation spends the same prepaid PicoBerry credits as the web app, per engine, at rates you can read with
list_modelsbefore you spend anything. (Using the API does require a completed purchase — see Get an API key.)
No install needed — run it with npx:
// Claude Code: .mcp.json · Claude Desktop: claude_desktop_config.json
{
"mcpServers": {
"picoberry": {
"command": "npx",
"args": ["-y", "@picoberry/mcp-server"],
"env": {
"PICOBERRY_API_KEY": "pb_live_xxxxxxxxxxxxxxxx"
}
}
}
}Cursor uses the same shape in ~/.cursor/mcp.json.
Sign in at https://picoberry.ai, open the API Keys tab in your dashboard, and hit Create key. The key is shown once — copy it immediately and treat it like a password.
API access needs a completed purchase: a subscription or a one-off credit pack. A purchase entitles you permanently — you don't need a current subscription. (An active paid subscription works too, of course.)
Var | Required | Default | Notes |
| ✅ | — |
|
| — |
| leave unset unless you were given a different host |
Related MCP server: higgsfield-mcp
Tool | What it does |
| Engines + credit cost for a category ( |
| Animation preset ids (engine-specific), with optional substring filter. |
| Current credit balance + plan. |
| Text → image (+ optional reference image URLs). |
| Text → 3D model (GLB). |
| Image → 3D model. Single: |
| Decompose one image into an exploded parts-board image (server-fixed engine). Input |
| Retopologize an existing 3D asset → new asset. |
| Re-texture (PBR) an existing 3D asset → new asset. |
| Auto-rig + animate an existing 3D character → new asset. |
| Status + result URLs for one asset. |
| Poll until an asset finishes (or times out), then return it. |
| Browse your generated assets. |
| Export a completed 3D asset ( |
Generation is asynchronous:
generate_3d_from_text({ prompt }) → returns an asset { id }.
wait_for_asset({ asset_id: id }) → polls until taskStatus === 2 (succeeded).
Read the result URL from files.model (GLB) or files.image (PNG).
taskStatus: 0 pending · 1 processing · 2 succeeded · 3 failed. Result
URLs are signed and short-lived — download promptly. Errors come back with an
actionable message (e.g. an unknown engine returns the list of valid names).
"Make a low-poly treasure chest, retopo it to 3k tris, and give me a Unity FBX."
list_models(category="3d") → pick an engine
generate_3d_from_text(prompt="low-poly treasure chest") → { id: A }
wait_for_asset(asset_id=A) → taskStatus 2
remesh(asset_id=A, polycount=3000) → { id: B }
wait_for_asset(asset_id=B)
download_asset(asset_id=B, format="fbx", texture_preset="unity") → signed URLRun this next to blender-mcp and the
agent can generate with PicoBerry, then import into Blender in one flow:
{
"mcpServers": {
"picoberry": { "command": "npx", "args": ["-y", "@picoberry/mcp-server"], "env": { "PICOBERRY_API_KEY": "pb_live_..." } },
"blender": { "command": "uvx", "args": ["blender-mcp"] }
}
}npm install
npm run build # tsc → dist/
PICOBERRY_API_KEY=pb_live_... npm startRun Actions → Publish → Run workflow (or push a v* tag). It publishes to
npm and then to the official MCP registry, in that order — the registry
validates by fetching the package's npm metadata and matching its mcpName
against server.json's name, so npm has to land first. A guard step checks
every invariant (name/version agreement, namespace casing, version not already
on npm) before anything is published, because npm versions are immutable and a
failed half-publish burns the number.
Bump version in both package.json and server.json (version and
packages[0].version) — the guard fails the run if they disagree.
One-time setup — no secrets. Both publishes authenticate over the workflow's
GitHub OIDC token (id-token: write). There is nothing to store or rotate.
The only step is telling npm to trust this workflow. On npmjs.com go to @picoberry/mcp-server → Settings → Trusted publishing → GitHub Actions and enter:
Field | Value |
Organization or user |
|
Repository |
|
Workflow filename |
|
Environment name | (leave empty) |
Allowed actions |
|
The workflow filename must match exactly — it is part of what npm verifies.
The MCP registry needs no setup at all: mcp-publisher exchanges the Actions
OIDC token, and the registry grants io.github.<repository_owner>/* from the
token's repository_owner claim. That covers io.github.UModeler/picoberry-mcp
and avoids the interactive browser login (which additionally requires org Owner).
Trusted Publishing needs npm >= 11.5.1, so the workflow runs on Node 24 (npm 11.x). Node 22 still bundles npm 10.9 and would fail — the
node-versionpin is load-bearing. A guard step fails the run early if the runner ever ships an older npm.
The namespace is compared byte-exactly —
io.github.UModeler/..., matching the GitHub org's login. A lowercasedio.github.umodeler/...is rejected 403.
After publishing, claim the Glama listing
— unclaimed servers get limited discoverability, and awesome-mcp-servers gates
its PRs on a Glama badge in CI.
MIT
Auto-rig an existing 3D character asset and apply an animation, producing a NEW asset (async). Pick preset from list_animation_presets for the SAME engine. Costs credits — see list_models(category='animate'). wait_for_asset → files.model.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | ||
| preset | No | ||
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: async nature ('async'), that it produces a new asset (non-destructive), costs credits, and that the result is accessible via 'wait_for_asset → files.model'. This adds value by outlining the asynchronous workflow and cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences delivering core purpose, async nature, preset guidance, cost reference, and post-processing step. Every sentence is necessary and the critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers essential context: what the tool does, async behavior, cost, prerequisite actions (list_animation_presets, list_models), and how to retrieve results (wait_for_asset). It is nearly complete for a 3-parameter tool, though it could mention the returned asset's structure more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context to parameters by mentioning 'asset_id' (existing asset), 'engine' (implied by 'SAME engine'), and 'preset' (from list_animation_presets). However, with 0% schema coverage, it does not fully describe each parameter's type, constraints, or optionality. It partially compensates through contextual hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Auto-rig an existing 3D character asset and apply an animation, producing a NEW asset (async).' It uses a specific verb ('auto-rig and apply') and resource ('existing 3D character asset'), and distinguishes it from sibling tools like 'generate_3d_from_text' and 'remesh' by focusing on animation application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important usage guidance: 'Pick `preset` from list_animation_presets for the SAME engine. Costs credits — see list_models(category='animate'). wait_for_asset → files.model.' It tells the user how to obtain the preset, check costs, and what to do after the call. While it lacks explicit 'when not to use', it effectively directs the agent to complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a completed 3D asset and get a short-lived signed download URL. glb = a single self-contained file. fbx/obj download as a .zip bundle (model + textures; + Unity .meta files when texture_preset='unity') — unzip before importing. For Unity use fbx (there is no built-in glb importer).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| format | No | glb | |
| asset_id | Yes | ||
| texture_preset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behaviors: signed URL is short-lived, formats produce different outputs (single file vs. zip with textures), and Unity .meta inclusion. Does not mention rate limits or auth, but adequately warns about zip handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then efficiently covers format differences and Unity advice in two sentences. No redundancy or wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, description addresses key aspects: output (signed URL), format handling, and Unity consideration. Lacks details on asset_id sourcing or URL expiry but sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning for 'format' (glb single self-contained file, fbx/obj zip), 'texture_preset' (unity adds .meta files), and implies 'asset_id' identifies a completed asset. Does not explain 'name' parameter, but overall adds value beyond schema enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Export a completed 3D asset and get a short-lived signed download URL', specifying verb (export/get), resource (3D asset), and outcome (URL). Distinguishes from sibling tools like get_asset (pure metadata) and generate tools (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (completed assets) and format-specific advice (glb single file, fbx/obj as zip, Unity recommendation). Lacks explicit exclusion or alternative tool guidance but sufficiently directs correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 3D model (GLB) from one image, or from 2–4 views of the same subject (multi-view → higher-fidelity geometry), async. Single: image_url (any public http/https image, or a prior generation's files.image) OR image_path (a local file, uploaded directly — no hosting needed). Multi-view: image_urls OR image_paths, ordered [front, left, back, right] (2–4 views). Multi-view is only supported by tripo*, meshy6, and hunyuan-3.x engines — others return 400. Local files win over URLs. Then wait_for_asset and read files.model. Costs credits — see list_models(category='3d').
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | ||
| texture | No | ||
| image_url | No | single hosted image URL | |
| polycount | No | ||
| image_path | No | absolute path to a single local image file (≤20MB) | |
| image_urls | No | multi-view: 2–4 hosted image URLs, ordered [front, left, back, right] | |
| image_paths | No | multi-view: 2–4 local image file paths (each ≤20MB), ordered [front, left, back, right] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses async behavior, a specific failure mode (400 for unsupported engines), input precedence (local files win over URLs), and cost implications. This is detailed behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: starts with the core action, then input modes, constraints, next steps, and costs. Each clause contributes useful information without redundancy, and the flow is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, async workflow, no output schema), the description covers the essential workflow, including how to retrieve the result via wait_for_asset and files.model, engine limitations, and credit costs. It is sufficiently complete for an agent to understand how to invoke and follow up.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57% (4 of 7 params). The description adds valuable meaning for image_url/image_path (public URLs, prior generation files, no hosting needed) and clarifies multi-view ordering and engine support. However, engine, texture, and polycount are not described in either schema or description, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a 3D model (GLB) from one or multiple images, distinguishing it from text-based generation and other sibling tools. It specifies input types (URLs or local paths) and the multi-view option, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: single vs multi-view, engine restrictions (tripo*, meshy6, hunyuan-3.x, others return 400), local files precedence over URLs, and the follow-up step to wait_for_asset and read files.model. It also directs users to list_models for credit information, acting as an alternative resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a game-ready 3D model (GLB) from a text prompt (async). Returns an asset { id }; call wait_for_asset (or poll get_asset) until taskStatus=2 and read files.model (GLB URL). Costs credits — see list_models(category='3d'). Omit engine for the default.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | engine name from list_models(category='3d') | |
| prompt | Yes | ≤1024 chars (Tripo engine limit) | |
| texture | No | ||
| polycount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses async behavior, return format, polling need, credit cost, and engine default. Adequately transparent for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states core function, second details workflow and cost. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return type and how to retrieve final model. Lacks error handling details but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning for prompt (char limit) and engine (default behavior) but does not describe texture or polycount beyond their schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates a game-ready 3D model (GLB) from a text prompt asynchronously. Distinct from siblings like generate_3d_from_image and generate_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides async workflow instructions (call wait_for_asset/poll get_asset), mentions cost and engine defaults. Does not explicitly contrast with siblings but gives sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 2D image from a text prompt (async). Returns an asset { id }; then call wait_for_asset (or poll get_asset) until taskStatus=2 and read files.image (PNG URL). Costs credits — see list_models(category='image'). Omit model for the default. Up to 4 reference image URLs can guide the result (best with nano-banana).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | engine name from list_models(category='image') | |
| prompt | Yes | ||
| aspect_ratio | No | e.g. "1:1", "16:9", "9:16" | |
| reference_image_urls | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async nature, cost (credits), default model behavior (omit for default), and reference image constraints (up to 4). No annotations exist, so description carries full burden. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences pack all essential info: action, async behavior, return type, next steps, cost, model default, and reference image limit. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the full async workflow, credit cost, and reference image usage. No output schema but explains expected response (asset id then PNG URL). Could mention error handling but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains model usage (omit for default), aspect_ratio examples, and reference_image_urls guide (best with nano-banana). Schema covers 50% of params; description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Generate a 2D image from a text prompt (async)' with specific verb and resource. Distinguishes from sibling tools like animate and 3D generation tools by focusing on 2D image generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow: returns asset id, then call wait_for_asset or poll get_asset until taskStatus=2, read files.image. Mentions credits, model omission, and reference image guidance. Lacks explicit when-not-to-use but is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a generation's status + result. taskStatus: 0=pending 1=processing 2=succeeded 3=failed. When succeeded, files.{model,image,thumbnail,textures} hold signed result URLs (short TTL — download promptly). On failure, read errorDetail.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses status codes, result URL structure (signed, short TTL), and failure handling via errorDetail. This provides useful behavioral context, though it could be enhanced with rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and includes essential details on status codes and result handling. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and no annotations, the description covers the key aspects: status retrieval, result URLs, and error handling. It is fairly complete for a simple status checker, though it omits details about pagination or response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter (asset_id) with no description, so the description must clarify its meaning. It does so by stating the tool gets a generation's status, implying asset_id is the generation identifier. However, it does not specify format or required usage beyond the schema's 'required' flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a generation's status and result, using the verb 'get' and specifying the resource 'generation'. It distinguishes itself from siblings like 'wait_for_asset' (which blocks) and 'download_asset' (which downloads) by focusing on status and result retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like wait_for_asset or download_asset. It does not specify prerequisites, typical use cases, or when not to use it. Only implied usage from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current PicoBerry credit balance and plan for the authenticated key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose side effects, rate limits, data freshness, or authentication requirements beyond mentioning the authenticated key. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could be improved by adding a brief note on return format without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but there is no output schema. The description does not specify the return value format (e.g., numeric balance, plan name), which is needed for the agent to use the response correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% by default. Per guidelines, 0 parameters warrant a baseline of 4. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the current credit balance and plan for the authenticated key, with a specific verb and resource. It distinguishes from sibling tools which are all about generation and asset management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use the tool or any prerequisites, such as authentication details. The description assumes the agent knows the context of the 'authenticated key' and provides no alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List animation preset ids for the animate tool. Presets are engine-specific (Tripo ~97 / Meshy ~675) — pick one from the SAME engine you animate with. Optionally filter with a case-insensitive substring.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | tripo | |
| search | No | case-insensitive filter on the preset name/category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description clarifies that presets are engine-specific and the tool is a read-only listing. It provides engine-counts and filtering behavior but does not detail other traits like rate limits or return structure. Still, it is transparent enough for safe use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no redundant words. Every sentence adds value: the first defines the tool, the second provides critical usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with two optional parameters and no output schema, the description covers all essential aspects: what it does, how to use it (same engine), and optional filtering. No gaps remain for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only `search` described). The description compensates by explicitly stating that presets are engine-specific and advising to match engines, which adds context beyond the schema's enum. The filtering behavior is also reiterated. This adds meaningful guidance for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists animation preset IDs for the `animate` tool, specifying engine-specific counts (Tripo ~97, Meshy ~675). This distinguishes it effectively from sibling tools like `animate` and other asset tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to pick presets from the same engine used for animation, and mentions optional case-insensitive filtering. While no alternative tools are named, the context makes usage clear for preparing presets before calling `animate`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available generation engines/models and their credit cost for a category. Call this before generating instead of hardcoding engine names. Returns [{ name, label, cost, paidOnly, ... }] — use name as the engine/model value.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | 3d |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return structure (array of objects with name, label, cost, paidOnly) and instructs the agent to use `name` as the engine/model value. This is meaningful above a simple purpose statement, though it doesn't cover error handling or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver purpose, usage, and return contract with no fluff. Information is front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and no output schema, the description covers why to call it, when to call it, and what it returns. The schema handles the parameter definition, so nothing critical is missing; it could mention pagination or filtering behavior, but those aren't applicable here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'category' parameter. The description mentions 'for a category' but doesn't elaborate on allowed values, defaults, or how the category affects the results beyond filtering the list; the enum and default are only in the schema, and no additional context is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing available generation engines/models with their credit costs per category, and explicitly instructs to use it before generating to avoid hardcoding engine names. This distinguishes it from sibling tools like get_credits (balance) and list_animation_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Call this before generating instead of hardcoding engine names,' providing a clear when-to-use rule. It does not mention alternative tools or when not to use it, so it falls short of full alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your generated assets (newest first, owner-scoped) for browsing/sync. Filter by category (3d/image/…) or keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| keyword | No | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides basic behavior: owner-scoped, newest first, filtering. However, it lacks details on permissions, rate limits, or edge cases, which is a gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, with two sentences that front-load the core purpose and then provide filtering details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main purpose and filtering, it does not address pagination behavior despite having page/limit parameters. For a tool with no output schema, this is a noticeable omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for 'keyword' and 'category' parameters but fails to mention 'page' and 'limit' parameters, which are critical for pagination. Given 0% schema description coverage, partial compensation is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing generated assets, scoped to the owner, with newest first ordering. This distinguishes it from sibling tools like get_asset (single asset) or generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for browsing/sync and mentions filtering, but does not explicitly state when not to use or provide alternatives among sibling tools like get_asset or list_models.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decompose one reference image into an exploded "parts board" image (async) — the subject laid out as separated components on one canvas. Input: asset_id (an existing IMAGE asset you own), image_url (a public http/https image), OR image_path (a local file, uploaded directly). Engine/resolution/prompt are server-fixed — no params. Returns an asset { id }; call wait_for_asset (or poll get_asset) until taskStatus=2 and read files.image (the board PNG). Feed that image to generate_3d_from_image for a parts-separated mesh. Costs 80 credits — see list_models(category='parts-board'). Precedence when several are set: image_path > asset_id > image_url.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | No | id of an existing IMAGE asset you own to decompose | |
| image_url | No | public http/https source image URL | |
| image_path | No | absolute path to a local image file (≤20MB), uploaded directly |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it is async, engine/resolution/prompt are server-fixed, returns an asset { id }, requires polling until taskStatus=2, output is accessible via files.image, and it costs 80 credits. This exceeds the typical transparency expected and leaves no hidden surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence contributes new information: purpose, input options, server-fixed constraints, return shape, polling workflow, downstream usage, cost reference, and precedence. It is front-loaded with the core purpose and efficiently packs all needed details without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (async, multiple input modes, downstream integration, cost), the description covers all critical aspects: the full workflow from input to polling to output consumption, prerequisite conditions (ownership, public URL, size limit), and integration with sibling tools. No output schema exists, but the description adequately explains the return format and subsequent steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters, but the description adds value beyond the schema by explaining the precedence order (image_path > asset_id > image_url), the requirement that asset_id must be an IMAGE asset you own, image_url must be public http/https, and image_path allows direct upload with a size limit (≤20MB). This enriches the parameter semantics significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb-resource pairing: "Decompose one reference image into an exploded 'parts board' image (async)" and clarifies the output as "the subject laid out as separated components on one canvas." It distinguishes itself from siblings like generate_image and generate_3d_from_image by specifying it produces a parts board and explicitly directs feeding the output to generate_3d_from_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: explains the async workflow (call wait_for_asset/poll get_asset until taskStatus=2), what to do with the result (feed to generate_3d_from_image), cost (80 credits), and where to find model details (list_models(category='parts-board')). It also states input precedence (image_path > asset_id > image_url), which is actionable guidance beyond basic alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retopologize an existing 3D asset into a NEW asset (async). Costs credits — see list_models(category='remesh') (pb-remesh is cheapest). wait_for_asset → files.model.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | ||
| asset_id | Yes | ||
| polycount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is async, creates a new asset (not modifying the original), costs credits, and outputs via 'files.model' from 'wait_for_asset'. It also hints at different engine options. Missing details on rate limits or permissions, but overall transparent for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a short reference. It front-loads the key action and async nature. Every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retopologizing (async, credits, output via another tool), the description provides sufficient context: it explains the async wait, credit cost, engine selection, and output format. It lacks an explanation of the 'polycount' parameter and does not cover error conditions, but overall it maps the user journey well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 3 parameters with 0% description coverage. The description adds meaning for 'asset_id' (the existing asset) and 'engine' (via reference to list_models). However, 'polycount' is not explained at all, leaving its purpose ambiguous. This partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Retopologize an existing 3D asset into a NEW asset (async).' It uses a specific verb ('retopologize') and distinguishes from sibling tools like 'generate_3d_from_text' or 'animate' by focusing on retopologizing an existing asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: it costs credits, is async, and suggests consulting 'list_models(category='remesh')' for the cheapest engine. It also tells the user to use 'wait_for_asset' to get the result. It does not explicitly state when not to use it, but the unique function and clear async/cost info make it useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-texture an existing 3D asset (PBR) into a NEW asset (async). Describe the desired look in prompt. Costs credits — see list_models(category='texture'). wait_for_asset → files.model.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | ||
| prompt | No | ||
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses async nature, credit costs, and how to retrieve output via wait_for_asset. However, it does not state side effects on the original asset (likely non-destructive) or mention any required permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero wasted words. It is front-loaded with the core action and efficiently packs async behavior, credit info, and result retrieval into a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description covers async nature, credit costs, and result retrieval. It omits explanation of the `engine` parameter and could clarify 'PBR' but overall is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the purpose of `prompt` ('Describe the desired look') and implies `asset_id` is the existing asset. However, the `engine` parameter is left undefined, and no default values or options are mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Re-texture', the resource 'existing 3D asset (PBR)', and the outcome 'NEW asset (async)'. It distinguishes from sibling tools like generate_3d_from_image/generate_3d_from_text which create assets from scratch, and animate which focuses on animation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage cues: 'Describe the desired look in `prompt`', points to list_models for credit info, and specifies wait_for_asset to retrieve the result. It implies when to use (retexturing existing asset) but lacks explicit exclusions or alternatives for cases like generating new textures from scratch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll an asset until it finishes (taskStatus 2 or 3) or the timeout elapses, then return the final asset. Use right after generate_* / remesh / texture / animate. 3D generations can take several minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | ||
| timeout_seconds | No | ||
| poll_interval_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully informs behavior: polls until taskStatus 2 or 3 or timeout, then returns final asset. It does not explicitly state non-destructive nature but polling implies no side effects. Could mention it does not modify state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no wasted words. Every sentence earns its place: first explains behavior, second gives usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers purpose and usage context but lacks parameter details and explicit return format. It says 'return the final asset', which is adequate but not exhaustive for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description does not explain parameters like asset_id, timeout_seconds, or poll_interval_seconds. While parameter names are somewhat self-explanatory, the description adds no additional semantics, leaving the agent to infer meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls an asset until it finishes or timeout, specifying verb 'poll' and resource 'asset'. It distinguishes from siblings like get_asset (which may not wait) and download_asset, and explicitly lists generative tools to use after.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use right after generate_* / remesh / texture / animate', providing strong positive guidance. It also notes that 3D generations take minutes, setting expectations. However, it lacks explicit exclusions or alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.5generate_3d_from_image4 fields changedInput schema / properties / image_path / descriptionPrevious value: -"absolute path to a local image file (≤20MB)"New value: +"absolute path to a single local image file (≤20MB)"Input schema / properties / image_pathsAdded value: +{
+ "description": "multi-view: 2–4 local image file paths (each ≤20MB), ordered [front, left, back, right]",
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 4,
+ "minItems": 2,
+ "type": "array"
+}Input schema / properties / image_url / descriptionAdded value: +"single hosted image URL"Input schema / properties / image_urlsAdded value: +{
+ "description": "multi-view: 2–4 hosted image URLs, ordered [front, left, back, right]",
+ "items": {
+ "format": "uri",
+ "type": "string"
+ },
+ "maxItems": 4,
+ "minItems": 2,
+ "type": "array"
+}list_models1 field changedInput schema / properties / category / enumPrevious value: -[
- "3d",
- "image",
- "remesh",
- "texture",
- "animate"
-]New value: +[
+ "3d",
+ "image",
+ "parts-board",
+ "remesh",
+ "texture",
+ "animate"
+]parts_boardv0.1.0animatedownload_assetgenerate_3d_from_imagegenerate_3d_from_textgenerate_imageget_assetget_creditslist_animation_presetslist_modelslist_my_assetsremeshtexturewait_for_assetMost tools have clearly distinct purposes: generation (image, 3D from text, 3D from image), transformation (remesh, texture, animate), and utility (list, get, download). The only notable overlap is get_asset vs wait_for_asset, but their descriptions clarify that wait_for_asset polls until completion while get_asset is a single status check.
Tool names mix conventions: list_* and get_* use consistent prefixes, generate_* is consistent, but remesh, texture, animate are single standalone verbs, and parts_board is a noun phrase. This mix is still readable and predictable within groups, but not uniform across the set.
14 tools is well-scoped for a 3D/2D asset generation server. The set covers generation, transformation, asset listing, status polling, and download, without unnecessary redundancy or overwhelming bloat.
The tool surface covers the core lifecycle: generate from text or image, transform existing assets (remesh, texture, animate), check status (get_asset, wait_for_asset), and download results. Minor gaps such as deleting assets or canceling jobs exist but do not block primary use cases.
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
Generate AI images and videos from any compatible MCP client.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/UModeler/picoberry-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
