PicoBerry MCP Server

remesh

Convert a 3D asset into a new retopologized model by specifying target polycount. Async job returns a file-based asset; credit costs apply—check list_models for options.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "asset_id": "<asset_id>"
    },
    "name": "remesh"
  }
}

Input Schema

Name	Required	Description	Default
`engine`	No
`asset_id`	Yes
`polycount`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 14, 2026

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server