Skip to main content
Glama

tripo_complete

Complete occluded geometry for parts created by tripo_segment, using AI completion or quick capping once the 3D project has been split.

Instructions

部件补全:给 tripo_segment 拆出的部件补齐被遮挡的几何。mode=ai 调 operation/ai_completion(AI 补全),mode=quick_cap 调 operation/mesh_fill(快速封口)。项目必须先拆分。

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": {
      "project_id": "<project_id>"
    },
    "name": "tripo_complete"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNo默认 ai
part_namesNo要处理的部件节点名;不填则取模型里全部部件
project_idYes
wait_secondsNo默认 480 秒
model_versionNoai 模式默认 v1.0-20250506,quick_cap 默认 default

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description does useful work by disclosing the two backend endpoints and the segmentation prerequisite. However, it never says whether the operation is in-place or produces a new project, whether it is long-running/async (the 480s wait_seconds hints at this but is unexplained), or what happens on partial failure.

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 short sentences, front-loaded with the purpose, then mode routing, then the prerequisite. No filler.

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?

For a 5-parameter mutation tool with no annotations and no output schema, the description covers purpose, mode semantics, and the prerequisite, but leaves the agent guessing about return values, blocking behavior, and whether results overwrite the source project.

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 80%, so the baseline is 3; the description earns above that by explaining what each mode actually does (ai → operation/ai_completion, quick_cap → operation/mesh_fill), which the schema's bare enum does not convey. It adds no detail on part_names or wait_seconds beyond the schema.

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 specific verb and resource ('部件补全' — fill in occluded geometry for parts) and ties it to the sibling that produces the input ('tripo_segment 拆出的部件'). An agent can distinguish this from tripo_remesh or tripo_segment without opening any schema.

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 an explicit prerequisite ('项目必须先拆分') and routes between the two modes by naming the backend operation each invokes. It does not say when to prefer this over alternatives like tripo_remesh, so it stops short of full when/when-not guidance.

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