trident-mcp

Overview Schema Source Related Servers Discussions Admin

multiview_to_model

Destructive

Generate a 3D mesh from 2-4 views of one object (front required) or from a successful image_to_multiview task. Returns a Tripo task ID; call wait_for_task to finish.

Instructions

Generate a 3D mesh from 2-4 views of one object (front required), or from a successful image_to_multiview / edit_multiview task. Creates a Tripo task (spends credits) and returns its task_id immediately; then call wait_for_task.

Input Schema

TableJSON Schema

Name	Required	Description
`pbr`	No	Generate PBR materials (default true); implies texture
`quad`	No	Quad topology; forces FBX output and 10k faces unless face_limit is set (+5 credits). Not on P1
`input`	No	Task ID of a successful image_to_multiview or edit_multiview task. Mutually exclusive with inputs
`model`	No	Model version: v3.1-20260211 (H3.1, default), v3.0-20250812, v2.5-20250123, P1-20260311 (low-poly), P2-20260801 (low-poly preview). Aliases such as v3.1, p1 and p2 work. See list_models.
`inputs`	No	Views of one object: front plus at least one of left, back, right. Each is a local path, URL or file token. Mutually exclusive with input
`delight`	No	Remove baked-in lighting from textures (default true). Only texture_version v3.5-20260815 reads it
`texture`	No	Generate textures (default true). false is cheaper and required for generate_parts
`compress`	No	Compress the output geometry (meshopt)
`auto_size`	No	Scale the mesh to real-world size in meters
`export_uv`	No	Include UVs in the output (default true)
`face_limit`	No	Target face count. H3.x up to 1.5M (2M with geometry_quality detailed); P1 50-20,000; P2 48-50,000; quad up to 150k
`model_seed`	No	Seed for geometry generation
`orientation`	No	align_image rotates the mesh to match the front image. Needs texture
`texture_seed`	No	Seed for texture generation
`generate_parts`	No	Generate separately editable parts (+20 credits). Requires texture false and pbr false. H3.x only
`smart_low_poly`	No	Hand-crafted-style low-poly topology on H3.x (+10 credits). Use P1/P2 for game-ready low poly instead
`texture_quality`	No	Texture quality (default standard). detailed is HD (+10 credits), extreme is 8K (+20). fast needs texture_version v3.5-20260815
`texture_version`	No	Texturing model version: v3.5-20260815, v3.0-20250812 or v2.5-20250123. Defaults to the one matching model
`geometry_quality`	No	detailed (Ultra) adds geometric detail (+20 credits). H3.x only
`texture_alignment`	No	Align textures to the original images (default) or to the geometry
`export_orientation`	No	Facing axis of the output (default +x). Later operations do not inherit it; prefer setting it on convert_model

Output Schema

TableJSON Schema

Name	Required	Description	Default
`model`	No
`task_id`	Yes
`produces`	Yes
`warnings`	No
`operation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Oct 19, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already disclose the write/destructive/non-idempotent profile, so the bar is lower. The description adds genuinely useful behavior: it spends credits and is asynchronous, returning a task_id immediately with wait_for_task as the completion path. It could say more about failure/refund behavior on a failed task.

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 with no waste: inputs first, then the async cost/return contract. Fully front-loaded and appropriately sized for a 21-parameter tool.

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?

With an output schema present and 100% parameter coverage plus annotations covering safety, the description supplies the one thing structured fields cannot: the create-then-wait_for_task workflow and that credits are consumed. Minor gaps remain around error handling, but nothing essential for correct invocation is missing.

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 the schema already documents the mutually-exclusive input/inputs fields and the front-required rule, so the description adds no syntax or constraint detail beyond it. Baseline 3 is appropriate when the schema does all the heavy lifting.

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 states a precise verb+resource ('Generate a 3D mesh') and names both input modes: 2-4 views of one object with front required, or the output of image_to_multiview / edit_multiview. This distinguishes it cleanly from siblings like image_to_model (single image) and text_to_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?

It specifies the conditions for use (2-4 views, front required, or an upstream multiview task) and names the required follow-up tool, wait_for_task. It stops short of explicitly naming the single-image alternative (image_to_model) as a when-not-to-use, so an agent must infer the boundary.

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