Skip to main content
Glama
Sign In
tripo-studio-mcp

tripo-studio-mcp

by Neko-Yukari
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

tripo_generate_image

Generate a 3D model from a local reference image, wait for processing, and download the resulting GLB file for 3D workflows.

Instructions

参考图生成 3D 模型。对应内部接口 operation/batch_image_to_model（单图即长度为 1 的数组），参数名与官方文档 image_to_model 一致。本地图片会先上传到 Tripo 并送审，默认阻塞等待并下载 GLB。

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": {
      "image_path": "<image_path>"
    },
    "name": "tripo_generate_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
pbrNoPBR 材质，默认 true；为 true 时 texture 被强制为 true
quadNo四边面输出，默认 false；开启后输出为 FBX 且面数不超过 150,000
textureNo是否生成贴图，默认 true
compressNo纹理压缩方式，默认 meshopt；geometry 需要在建模软件里先解压
out_pathNo保存路径，默认 tripo-out/<文件名>.glb
auto_sizeNo按真实世界尺寸（米）缩放，默认 false
export_uvNo生成阶段是否做 UV 展开，默认 true；设 false 更快、模型更小
face_limitNo面数上限，不填自适应。v3.1/v3.0 detailed 最多 2,000,000、standard 1,500,000；v2.5 最多 500,000；quad=true 时不超过 150,000
image_pathYes本地图片路径（png/jpg/webp），建议分辨率 ≥256×256
model_seedNo几何随机种子，固定可复现（v2.0 及以上）
visibilityNo模型可见性，默认 shareable
face_presetNo面数预设：low 3万 / medium 15万 / high 80万，优先于 face_limit；游戏资产和 3D 打印建议 low 或 medium
orientationNo自动旋转对齐原图，默认 default；仅 texture=true 时生效
texture_seedNo贴图随机种子（v2.0 及以上）
wait_secondsNo阻塞等待上限，默认 480 秒；超时会返回 id，稍后用 tripo_download 取模型
model_versionNo模型版本，默认 v3.1-20260211（H3.1）。v3.0 = H3.0 快速，v2.5 = H2.5 经典；Nexus-v1.0 / Nexus-v2.0 = 智能网格 P1.0 / P2.0（对应官方 API 的 P1，输出干净拓扑低模）
generate_partsNo分部件生成，默认 false；与 texture/pbr/quad 不兼容
smart_low_polyNo手搓拓扑低模，默认 false；输入复杂时可能失败
texture_qualityNo贴图质量，默认 detailed；standard 为基准，detailed +20、extreme +30 积分
geometry_qualityNo几何精度，默认 detailed（Ultra）
texture_alignmentNo贴图对齐倾向：忠于原图 / 忠于几何，默认 original_image
enable_image_autofixNo生成前先优化输入图，默认 false

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it discloses several non-obvious traits: local files are uploaded to Tripo and pass moderation review, the call blocks by default and downloads the GLB. It omits cost implications (the schema notes credit surcharges for texture_quality) and typical generation latency, which for a long-blocking paid operation would be valuable.

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?

Three tight sentences, front-loaded with the core action before the implementation mapping and runtime behavior. The internal-endpoint mapping sentence is arguably developer-facing noise, but it is short and does not bury the actionable 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?

For a 22-parameter generation tool with full schema coverage and no output schema, the description covers the essential gaps: what it produces (GLB), that it blocks, and how to recover on timeout. Missing pieces are cost/credit disclosure and expected duration, which matter for a paid, long-running generation.

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 100% and every one of the 22 parameters has its own documented default and enum semantics, so the schema does the heavy lifting. The description only adds that parameter naming mirrors the official image_to_model API and that a single image is a length-1 array — metadata, not semantic enrichment. Baseline 3 applies.

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

Purpose4/5

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

States a concrete verb+resource ('参考图生成 3D 模型') and ties it to the underlying operation name (batch_image_to_model), which also clarifies that multi-image is supported via an array. It never names the sibling it competes with (tripo_generate_text / tripo_generate_multiview), so the agent must infer the 1-image vs multi-view distinction from the tool name and description alone.

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 when to use it (single reference image → 3D model) and explains the default behavior of blocking and downloading the GLB. But it gives no explicit when-not or alternative routing — e.g. when to prefer tripo_generate_multiview, or that tripo_download/tripo_status is the path on timeout (only implicit via '默认阻塞等待').

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

Deploy Server

Other Tools