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 "Deploy 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). Not every engine takes multi-view — check supportsMultiView from list_models(category='image-to-3d'); unsupported engines return 400. Local files win over URLs. Then wait_for_asset and read files.model. Costs credits — see list_models(category='image-to-3d') (NOT category='3d', which is the text-to-3D catalog and omits image-only engines).
| Name | Required | Description | Default |
|---|---|---|---|
| engine | No | engine name from list_models(category='image-to-3d') | |
| 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] | |
| ultra_mode | No | higher-fidelity geometry. Only engines whose list_models entry has supportsUltraMode (currently meshy-7), and SINGLE image only — the vendor scopes it to one input image. Adds that entry's ultraCost credits. Combining it with another engine or with multi-view returns 400. | |
| 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, the description carries the full burden and does so thoroughly: it discloses async behavior, credit costs, local-file precedence ('Local files win over URLs'), unsupported-engine 400 errors, and the GLB/files.model result to read.
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 front-loads the core purpose and every sentence earns its place, including the catalog disambiguation and cost warning. It is appropriately sized for an 8-parameter tool.
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 description covers input modes, engine compatibility, cost, error behavior, and follow-up asset access, which is substantial for a tool with no output schema. It does not explicitly state that an engine is required, but from schema and the engine param description an agent can infer it.
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 75% and the description compensates by explaining the single vs multi-view alternatives, the [front, left, back, right] ordering, accepted URL forms including prior generation files.image, and the no-hosting-needed local file option. It does not add meaning for texture or polycount, but those are self-evident or covered elsewhere.
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 opens with a precise verb and resource: 'Generate a 3D model (GLB) from one image, or from 2–4 views of the same subject (multi-view → higher-fidelity geometry), async.' It clearly distinguishes from siblings by noting the image-to-3D category and contrasting with the text-to-3D catalog in the cost note.
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 gives explicit when-to-use guidance: check supportsMultiView before multi-view input, expect a 400 on unsupported engines, and use list_models(category='image-to-3d') rather than category='3d' (text-to-3D). It also prescribes the follow-up workflow: 'Then wait_for_asset and read files.model.'
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') — the text-to-3D catalog | |
| 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, the prose carries the behavioral burden and it does well: it discloses asynchrony, the returned asset shape, the required polling condition, the GLB download location, and credit consumption. It does not cover failure modes or side effects beyond cost, but the core behavioral contract is explicit.
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 dense sentences carry the essential behavior, polling recipe, cost caveat, and engine default with no filler. The most important action and output are front-loaded, and each clause adds information the agent needs before calling the tool.
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 no-output-schema tool with no annotations, this description covers the return contract, completion condition, destination of the GLB, credit cost, and engine sourcing. The main omissions are the semantics of texture/polycount and explicit failure handling, but an agent can invoke the core workflow correctly from this text.
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 engine semantics by pointing to the catalog and the 'omit for default' rule, which goes beyond the schema. However, schema coverage is only 50% and texture and polycount remain undocumented in both the schema and the prose, leaving part of the parameter surface unexplained.
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 opening clause names a specific verb ('Generate'), a concrete output artifact ('game-ready 3D model (GLB)'), and the input modality ('from a text prompt'). It also marks the operation as async, which distinguishes it from synchronous siblings and ties it to the follow-up asset workflow described next.
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 gives actionable when-to-use context: it tells the agent to wait via wait_for_asset or poll get_asset, and to consult list_models for engine choices. It stops short of explicitly contrasting when to prefer generate_3d_from_image or other siblings, so it earns a strong 4 rather than a 5.
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 | W:H, e.g. "1:1", "16:9", "9:16", "21:9". Use a value from the model's supportedAspectRatios in list_models(category='image') — nano-banana models reject anything else with 400 before charging credits; gpt-image-* buckets any ratio to its nearest of three output sizes. | |
| reference_image_urls | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses async behavior, the return shape (asset { id }), the need to poll until taskStatus=2, the output location (files.image PNG URL), and credit costs. This is unusually transparent.
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?
Four dense sentences with no filler. The main purpose is front-loaded, and each sentence adds workflow, cost, model, or reference-image guidance. Every word earns its place.
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?
Despite no output schema and no annotations, the description explains the async lifecycle, return asset ID, polling condition, final PNG URL, credit implications, model selection, and reference-image limits. An agent has what it needs to invoke the tool and handle the result.
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 only 50%, so the description adds needed meaning: 'text prompt' for prompt, 'guide the result' and 'best with nano-banana' for reference_image_urls, and default model behavior. The schema already covers aspect_ratio and model, so the description compensates for the uncovered params.
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?
States a specific verb ('Generate'), a specific resource ('2D image from a text prompt'), and the async nature. It distinguishes itself from siblings like generate_3d_from_text and generate_3d_from_image by explicitly saying '2D'.
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 context on the follow-up workflow (wait_for_asset/get_asset), credit costs, and how to select models. It does not explicitly exclude 3D or animation alternatives, though the '2D image' phrasing implies the boundary.
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, supportsMultiView, supportsUltraMode, ultraCost, ... }] — use name as the engine/model value. NOTE: the two 3D surfaces are SEPARATE catalogs — 3d is text-to-3D, image-to-3d is image-to-3D. An unrecognized category silently falls back to 3d, so a guessed value returns a plausible list that is missing image-only engines.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | `3d` lists TEXT-to-3D engines only. Engines whose vendor takes image input alone (e.g. meshy-7) have no text-to-3D row and appear ONLY under `image-to-3d` — use that before generate_3d_from_image. | 3d |
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 a significant behavioral trait that would otherwise be invisible: 'An unrecognized category silently falls back to `3d`', so a guessed value returns a plausible list missing image-only engines. It also explains that the two 3D catalogs are separate. It stops short of explicitly stating the call has no side effects, but for a 'list' tool that is implied.
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 front-loaded with the core purpose and instruction, then gives return-shape detail and ends with the critical warning. Each sentence earns its place, though the prose is slightly dense because it avoids bullet points. It is not bloated, but it packs a lot into a paragraph.
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 single-category listing tool with no output schema, the description covers the essential context: when to call it, what the response looks like, and the important caveat about unrecognized categories. It does not document pagination or result limits, but these are not substantial for this simple tool design, so the completeness is solid but not perfect.
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 100%, and the enum already gives exhaustive options. The description adds non-obvious semantics beyond the schema by warning about the silent fallback and highlighting that `3d` and `image-to-3d` are independent catalogs. It also clarifies that the returned `name` is the value to send as the engine/model, which is useful for the output side of the tool.
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 a specific verb and resource: 'List available generation engines/models and their credit cost for a category.' It differentiates itself from sibling generation tools by saying 'Call this before generating instead of hardcoding engine names.' This makes it evident how list_models is distinct from generate_image, generate_3d_from_text, 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?
Explicit when-to-use guidance appears both in the description ('Call this before generating instead of hardcoding engine names') and in the schema's category parameter description ('use that before generate_3d_from_image'). It tells the agent when to use the tool and which sibling alternative applies for image-to-3D, leaving no ambiguity about when to call it.
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.
v0.1.6generate_3d_from_image2 fields changedInput schema / properties / engine / descriptionAdded value: +"engine name from list_models(category='image-to-3d')"Input schema / properties / ultra_modeAdded value: +{
+ "description": "higher-fidelity geometry. Only engines whose list_models entry has supportsUltraMode (currently meshy-7), and SINGLE image only — the vendor scopes it to one input image. Adds that entry's ultraCost credits. Combining it with another engine or with multi-view returns 400.",
+ "type": "boolean"
+}generate_3d_from_text1 field changedInput schema / properties / engine / descriptionPrevious value: -"engine name from list_models(category='3d')"New value: +"engine name from list_models(category='3d') — the text-to-3D catalog"generate_image3 fields changedInput schema / properties / aspect_ratio / descriptionPrevious value: -"e.g. \"1:1\", \"16:9\", \"9:16\""New value: +"W:H, e.g. \"1:1\", \"16:9\", \"9:16\", \"21:9\". Use a value from the model's supportedAspectRatios in list_models(category='image') — nano-banana models reject anything else with 400 before charging credits; gpt-image-* buckets any ratio to its nearest of three output sizes."Input schema / properties / aspect_ratio / patternAdded value: +"^[1-9]\\d?:[1-9]\\d?$"Input schema / properties / prompt / maxLengthPrevious value: -5000New value: +4000list_models2 fields changedInput schema / properties / category / descriptionAdded value: +"`3d` lists TEXT-to-3D engines only. Engines whose vendor takes image input alone (e.g. meshy-7) have no text-to-3D row and appear ONLY under `image-to-3d` — use that before generate_3d_from_image."Input schema / properties / category / enumPrevious value: -[
- "3d",
- "image",
- "parts-board",
- "remesh",
- "texture",
- "animate"
-]New value: +[
+ "3d",
+ "image-to-3d",
+ "image",
+ "parts-board",
+ "remesh",
+ "texture",
+ "animate",
+ "uv-unwrap"
+]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_assetScored across 14 tools
The tools mostly have distinct purposes, and descriptions clearly separate generation, post-processing, and retrieval. However, get_asset, wait_for_asset, and download_asset all return asset-related outcomes and could initially be confused, and generate_image vs generate_3d_from_image require careful reading to pick the right one.
Most tools follow a clear verb_noun pattern (list_*, get_*, generate_*, download_*), but there are small deviations: generate_image lacks the "from_text" detail that generate_3d_from_image/text have, and parts_board is a noun phrase rather than a verb-based name. The overall style is readable and only mildly inconsistent.
Fourteen tools cover generation, post-processing (remesh, texture, animate, parts_board), and asset management (list, get, wait, download, credits). This is a well-scoped number, and each tool has a clear role with no obvious bloat or excessive overlap.
The server covers core workflows: 2D and 3D generation, common post-processing transforms, result retrieval, and export. The main missing piece is an imported-3D-asset upload path (you can only modify assets created within the system) and asset deletion, but these are relatively minor gaps and do not cause dead ends in normal use.
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
Generate AI images and videos from any compatible MCP client.
Generate images, video, audio and short films with 140+ AI models from any MCP client.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
