Skip to main content
Glama

Generate a 3D model from an image

generate_model

Generate a 3D model (GLB) from one photo of an object. This is asynchronous and usually takes 3-7 minutes: the call returns a task_id immediately and get_generation reports progress. The result is downloadable only by the calling account and does not enter the public library. This tool charges credits, computed server-side and returned as credits_cost, so a call that cannot afford it is refused before any work starts. Supply image_base64 or image_urls to generate now, or omit both to have the user upload an image through their browser.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierYesOutput detail, from least to most. 'low' = 1024px texture, maximum 100K faces; 'medium' = 2048px, maximum 200K faces; 'high' = 2048px, maximum 500K faces; 'ultra' = 4096px, maximum 1M faces. Every tier costs the same 6 credits. The reconstruction resolution is the same for every tier, so this only decides how much detail comes back. Each step produces a larger file (4 MB to 40 MB); the price is not proportional to the size because most of the cost is fixed per generation.
image_urlsNoA direct URL of the source image. Exactly one: the model reconstructs the object from that photo alone, estimating the camera itself, so a second angle is refused rather than ignored. Ignored when image_base64 is also supplied.
image_base64NoBase64 of the source image, without the data:image/... prefix. Compress to 1024x1024 JPEG before encoding: a 1024^2 JPEG is about 0.2 MB and roughly 270 KB encoded, which fits in a context window, while a 4 MB phone photo becomes about 5.3 MB of text and will be truncated or corrupted on the way in. Server limit is 10 MB encoded. JPEG or PNG only. Takes precedence over image_urls when both are given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • removedInput schema / properties / faces
      Removed value: -{
      -  "description": "Mesh density in triangles: 'light' = about 200K, 'standard' = about 1M, 'fine' = about 5M. Higher density means a larger file (8 MB to 168 MB).",
      -  "enum": [
      -    "light",
      -    "standard",
      -    "fine"
      -  ],
      -  "type": "string"
      -}
    • changedInput schema / properties / image_base64 / description
      Previous value: -"Base64 of the source image, without the data:image/... prefix. Compress to 1024x1024 JPEG before encoding: a 1024^2 JPEG is about 0.2 MB and roughly 270 KB encoded, which fits in a context window, while a 4 MB phone photo becomes about 5.3 MB of text and will be truncated or corrupted on the way in. Server limit is 10 MB encoded. JPEG or PNG only. Takes precedence over image_urls when both are given. Always single-view: use image_urls to supply several angles."New value: +"Base64 of the source image, without the data:image/... prefix. Compress to 1024x1024 JPEG before encoding: a 1024^2 JPEG is about 0.2 MB and roughly 270 KB encoded, which fits in a context window, while a 4 MB phone photo becomes about 5.3 MB of text and will be truncated or corrupted on the way in. Server limit is 10 MB encoded. JPEG or PNG only. Takes precedence over image_urls when both are given."
    • changedInput schema / properties / image_urls / description
      Previous value: -"Direct URLs of 1-4 images of the SAME object, in orbit order starting from the front. One URL is a normal single-view generation. Two or more switch to multi-view reconstruction, which is more accurate about the parts a single photo cannot show; the first URL is treated as the front view and the rest are spaced evenly around the object, so the order matters. Ignored when image_base64 is also supplied."New value: +"A direct URL of the source image. Exactly one: the model reconstructs the object from that photo alone, estimating the camera itself, so a second angle is refused rather than ignored. Ignored when image_base64 is also supplied."
    • removedInput schema / properties / quality
      Removed value: -{
      -  "description": "Generation resolution: 'normal' = 1024, 'high' = 1536. Higher takes longer and costs more. This is the geometry axis; use texture and faces for the surface and mesh density.",
      -  "enum": [
      -    "normal",
      -    "high"
      -  ],
      -  "type": "string"
      -}
    • removedInput schema / properties / texture
      Removed value: -{
      -  "description": "Texture resolution: 'standard' = 1024, 'high' = 2048, 'ultra' = 4096. Controls surface detail only; use faces to control mesh density.",
      -  "enum": [
      -    "standard",
      -    "high",
      -    "ultra"
      -  ],
      -  "type": "string"
      -}
    • addedInput schema / properties / tier
      Added value: +{
      +  "description": "Output detail, from least to most. 'low' = 1024px texture, maximum 100K faces; 'medium' = 2048px, maximum 200K faces; 'high' = 2048px, maximum 500K faces; 'ultra' = 4096px, maximum 1M faces. Every tier costs the same 6 credits. The reconstruction resolution is the same for every tier, so this only decides how much detail comes back. Each step produces a larger file (4 MB to 40 MB); the price is not proportional to the size because most of the cost is fixed per generation.",
      +  "enum": [
      +    "low",
      +    "medium",
      +    "high",
      +    "ultra"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "quality",
      -  "texture",
      -  "faces"
      -]New value: +[
      +  "tier"
      +]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: asynchronous with a 3-7 minute runtime, immediate task_id return, credit charging with server-computed credits_cost, pre-flight refusal when unaffordable, and a privacy guarantee that results are visible only to the calling account and stay out of the public library.

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?

A single dense block, front-loaded with the what (generate GLB from one photo) before the async/credit/parameter mechanics. Nearly every clause carries information, though the precedence sentence partially duplicates the schema.

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 an async generation tool with no annotations and no output schema, the description still covers the full lifecycle an agent needs: initiation, the returned task_id, polling via get_generation, cost behavior, failure-before-work, and result visibility.

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 100%, so the baseline is 3, but the description adds genuine behavior beyond the schema: the 'omit both and the user uploads through their browser' mode is not stated anywhere in the schema. It also re-states the base64-over-urls precedence the schema already documents, which is redundant but not harmful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource ('Generate a 3D model (GLB)') and pins the input modality to 'one photo of an object'. An agent can distinguish it immediately from read-side siblings like get_generation, get_model, and download_model.

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?

Gives clear operating context: supply image_base64 or image_urls to generate now, or omit both for browser upload, and it names get_generation as the progress-polling follow-up. It lacks an explicit 'use this instead of X' exclusion, but no sibling competes for the same generation job.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources