PicoBerry MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.5
Disambiguation4/5
Most 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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.2/5 across 14 of 14 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/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 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![picoberry-mcp MCP server](https://glama.ai/mcp/servers/UModeler/picoberry-mcp/badges/card.svg)](https://glama.ai/mcp/servers/UModeler/picoberry-mcp)

Score Badge

Copy to your README.md:

[![picoberry-mcp MCP server](https://glama.ai/mcp/servers/UModeler/picoberry-mcp/badges/score.svg)](https://glama.ai/mcp/servers/UModeler/picoberry-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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