trident-mcp is an AI-powered 3D model generation and post-processing server (Go-based, using Tripo as the backend) that lets you create, convert, and refine 3D models using text, images, or multi-angle views.
3D Model Generation:
text_to_3d — Generate a 3D model from a text prompt, with optional negative prompt, face limit, and model version selection.
image_to_3d — Generate a 3D model from a single reference image (local path or public URL), with options for orientation, texture quality, and face limit.
multiview_to_3d — Generate higher-quality 3D models from 2–4 reference images taken from different angles.
Task Management:
task_status — Poll the progress of any async generation or post-processing task (queued, running, success, or failed).
download_model — Download a completed 3D model to a local file.
Post-processing:
convert_format — Convert a model to a different file format: GLTF, FBX, OBJ, STL, USDZ, or 3MF.
retopologize — Create a low-poly version of a model with a target face count in quad or triangle mesh.
stylize — Apply a stylization effect: lego, voxel, voronoi, or minecraft.
Server Introspection:
list_models — List supported model versions and their capabilities.
get_config — View the active backend, output directory, and server version.
Provides tools for 3D model generation and post-processing, with companion skills designed to integrate with Blender for automated 3D modeling workflows.
Supports automated testing and release processes through GitHub Actions, including unit checks on pushes/pull requests and E2E smoke tests on main branches and version tags.
trident-mcp is a Go MCP server for AI-assisted 3D model generation and post-processing. It runs as a single stdio binary and currently uses the Tripo v3 API behind provider capability interfaces.
Build locally:
go build -o ./trident-mcp ./cmd/trident-mcpRun with a Tripo key:
TRIPO_API_KEY=tsk_your_key_here ./trident-mcpOne-command development bootstrap and smoke check:
go mod download && go install github.com/golangci/golangci-lint/cmd/golangci-lint@v2.11.4 && go test ./... -count=1Related MCP server: gemini-media-mcp
{
"mcpServers": {
"trident-mcp": {
"command": "trident-mcp",
"env": {
"TRIPO_API_KEY": "tsk_your_key_here",
"MODEL_OUTPUT_DIR": "/absolute/path/to/generated_models"
}
}
}
}Need | Read |
Agent instructions and common change patterns | |
Architecture, module boundaries, and Mermaid diagrams | |
MCP tool surface, models, and Tripo v3 behavior notes | |
Local setup, verification commands, and release workflow | |
Runtime config, E2E tests, and operational caveats | |
Design invariants and provider-boundary rationale | |
Architecture decision records | |
Security policy and threat model |
Variable | Required | Default | Description |
| Yes | none | Tripo API key used for generation, polling, download, and post-processing calls |
| No |
| Override for private deployments or tests |
| No |
| Directory where downloaded models are written |
The server exposes tools for text/image/multiview 3D generation, image preparation, splats, async task polling, account balance and usage, file uploads, downloads, conversion, retopology, stylization, texture/refine/segment/complete workflows, rig checks, rigging, animation retargeting, and model/config inspection.
See docs/MCP_TOOLS.md for the full tool contract and known Tripo v3 quirks.
The normal local gate is:
go build ./cmd/trident-mcp
go test ./... -count=1
go vet ./...
golangci-lint run
go run golang.org/x/vuln/cmd/govulncheck@latest ./...Live E2E tests require TRIPO_API_KEY and can spend credits when opt-in generation flags are set. See docs/OPERATIONS.md.
Apache-2.0. See LICENSE.
Complete a segmented model or selected parts.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Segmentation task ID or model source | |
| model | No | Optional completion model version | |
| partNames | No | Part names to complete |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose what 'complete' entails, side effects, requirements, or any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but could be slightly expanded for better clarity without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present, the description lacks behavioral context, usage guidance, and parameter details, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already explains parameters. The description adds minimal extra meaning by mentioning 'selected parts' aligning with 'partNames'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool completes a segmented model or selected parts, using a specific verb and resource. However, it does not differentiate from the sibling 'segment_mesh', which is closely related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies usage after segmentation but provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a generated 3D model to a different file format (GLTF, FBX, OBJ, STL, USDZ, 3MF). This is an async operation — use task_status to poll progress, then download_model to retrieve the converted file.
| Name | Required | Description | Default |
|---|---|---|---|
| bake | No | Bake material textures during conversion | |
| quad | No | Convert to quad mesh output when supported | |
| format | Yes | Desired output format: GLTF, FBX, OBJ, STL, USDZ, or 3MF | |
| packUV | No | Pack UVs during conversion | |
| faceLimit | No | Target face count for converted output | |
| fbxPreset | No | FBX preset when exporting FBX, such as unity or unreal | |
| partNames | No | Specific segmented part names to export | |
| scaleFactor | No | Scale multiplier for converted output | |
| textureSize | No | Target texture size for converted output | |
| textureFormat | No | Texture image format, such as png, jpg, or webp | |
| originalTaskId | Yes | Task ID of the model to convert | |
| exportOrientation | No | Target export orientation: +x, -x, +y, or -y. x_up and y_up are accepted as aliases | |
| exportVertexColors | No | Export vertex colors when supported | |
| pivotToCenterBottom | No | Move pivot to the model center-bottom |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the operation is async and guides the user to use task_status and download_model. However, it does not disclose other behavioral traits such as whether the operation is destructive (e.g., whether the original model is modified), rate limits, or authentication requirements. Given that annotations are missing, the description carries the full burden but falls short of complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that include the main purpose, supported formats, and async workflow. Every sentence adds value with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, async behavior) and the existence of an output schema, the description provides sufficient context for the high-level flow (convert, poll, download). It could be slightly more explicit about the return value type (task ID), but overall it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all 14 parameters are already documented in the input schema. The description adds no extra meaning beyond the schema, so it meets the baseline expectation but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb (convert) and resource (3D model), lists the supported output formats, and distinguishes from sibling tools like image_to_3d or import_model by focusing on format conversion. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (after having a generated 3D model) and explains the async workflow with steps for polling and downloading. However, it does not explicitly state when not to use it or compare with alternatives like text_to_3d, which is a minor omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a presigned upload URL and file token for large Tripo file uploads.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | File extension without leading dot, such as glb, fbx, png, or webp |
| Name | Required | Description |
|---|---|---|
| expiresIn | Yes | |
| fileToken | Yes | |
| presignedUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the creation of a presigned URL and token but omits important behavioral details such as URL expiration, prerequisite permissions, side effects, or that this is a setup step before actual file upload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. It is front-loaded with the core functionality and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be described. However, the description does not explain how the presigned URL and token fit into the upload workflow (e.g., subsequent use with 'upload_file'). It is adequate for a simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds examples of valid formats (glb, fbx, etc.) beyond the schema's description. However, it does not explain the parameter in depth or mention any other parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool creates a presigned upload URL and file token for large Tripo file uploads. It uses a specific verb ('Create') and identifies the resource, distinguishing it from siblings like 'upload_file' which implies a different upload method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for large Tripo file uploads but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools like 'upload_file' for smaller files. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a completed 3D model to a local file using the task's actual output format. If you need a different format, run convert_format first, then download the conversion task.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Optional expected task output format to validate: GLTF, FBX, OBJ, STL, USDZ, or 3MF. Use convert_format before download_model to change formats. | |
| taskId | Yes | Task ID of the completed generation |
| Name | Required | Description |
|---|---|---|
| format | Yes | |
| taskId | Yes | |
| filePath | Yes | |
| modelVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that this tool downloads to a local file and requires a completed task, but doesn't mention authentication needs, rate limits, file size constraints, or what happens if the task isn't completed. It adds some context about format handling but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides crucial usage guidance. There's zero wasted language and it's front-loaded with the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 100% schema coverage, and clear purpose/guidelines, the description is mostly complete. However, as a download operation with no annotations, it could benefit from mentioning potential behavioral aspects like file size limits or download location defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full documentation of both parameters. The description adds value by explaining the relationship between 'format' parameter usage and the 'convert_format' alternative, but doesn't provide additional semantic context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download a completed 3D model to a local file') and resource ('using the task's actual output format'), distinguishing it from sibling tools like 'convert_format' which changes formats rather than downloading. It explicitly contrasts with the alternative workflow for different formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Download a completed 3D model') versus when to use an alternative ('If you need a different format, run convert_format first, then download the conversion task'). It clearly names the alternative tool and specifies the sequence of operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing multiview image set with per-view prompt instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | Target view for prompt: front, left, back, or right | |
| input | Yes | Multiview task ID, image URL, or file token | |
| prompt | No | Convenience edit instruction. If view is omitted, applies to all four views | |
| prompts | No | Per-view edit instructions. Each entry requires prompt and view |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'Edit' without explaining whether it mutates the original, requires authorization, or has rate limits. Output schema exists but behavior details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is efficient and front-loaded, though could be slightly more structured to separate purpose from behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema covers return values, but description lacks detail on editing semantics (e.g., incremental vs replace) and prerequisites. Adequate but not comprehensive for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds the phrase 'per-view prompt instructions', which aligns with the prompts parameter but doesn't add new meaning beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Edit' and resource 'existing multiview image set', with specific detail about 'per-view prompt instructions', distinguishing it from creation or conversion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for editing multiview images with prompts, but no explicit guidance on when to use this versus alternatives like image_to_multiview or multiview_to_3d, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the Tripo account's available and frozen credit balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| frozen | Yes | |
| balance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly identifies a read-only operation ('Query') but does not disclose other behavioral traits like authentication needs, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description provides essential context. However, it could have clarified the difference from get_usage or mentioned the returned fields more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so baseline is 4. The description adds no parameter info but is sufficient for a zero-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Query') and resource ('Tripo account's available and frozen credit balance'), which is specific and distinct from sibling tools like get_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as get_usage. The description provides no context on selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show current server configuration including active backend and output directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| backend | Yes | |
| version | Yes | |
| outputDir | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool shows configuration, implying a read-only operation, but doesn't disclose critical traits like whether it requires authentication, has rate limits, or returns real-time vs. cached data. The description is minimal and lacks depth beyond the basic action, leaving behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Show current server configuration') and specifies what's included. There is zero waste or redundancy, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations) and the presence of an output schema, the description is adequate but minimal. It states what the tool does but lacks context on usage scenarios, behavioral details, or integration with siblings. The output schema likely covers return values, so the description doesn't need to explain those, but it could benefit from more completeness regarding when and why to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids discussing inputs. Baseline for 0 parameters is 4, as the description correctly focuses on the tool's purpose without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'Show' and specifies the resource as 'current server configuration', including what it contains ('active backend and output directory'). It distinguishes itself from siblings like list_models or task_status by focusing on server settings rather than models or tasks. However, it doesn't explicitly differentiate from all siblings (e.g., it's clear but not exhaustive in sibling comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., server must be running), exclusions, or comparisons to other tools. For example, it doesn't clarify if this is for debugging, setup verification, or general monitoring, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status and output metadata for a Tripo task by task ID.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID from a previous generation or post-processing call |
| Name | Required | Description |
|---|---|---|
| type | No | |
| error | No | |
| output | No | |
| status | Yes | |
| taskId | Yes | |
| progress | Yes | |
| createdAt | No | |
| rawOutput | No | |
| completedAt | No | |
| creditsConsumed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the operation as a read but does not disclose error handling, idempotency, or any safety aspects. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and object, no waste. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, output schema exists), the description is sufficient. It covers the core purpose, though it could hint at typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra meaning beyond what the schema already provides for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves status and metadata for a Tripo task by ID, using a specific verb and resource. It distinguishes from the plural 'get_tasks' and similar 'task_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing a specific task's status, but does not explicitly state when to use versus alternatives like 'task_status' or 'get_tasks'. No exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch query up to 100 Tripo tasks by task ID.
| Name | Required | Description | Default |
|---|---|---|---|
| taskIds | Yes | Task IDs to query, maximum 100 |
| Name | Required | Description |
|---|---|---|
| tasks | Yes | |
| missed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the batch limit of 100 and query method but lacks details on error handling, idempotency, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single 9-word sentence. No wasted words; every piece is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter design and the existence of an output schema, the description adequately covers the essential constraints. However, it could mention read-only nature since no annotations are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reinforces the limit but does not add new semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'batch query', the resource 'Tripo tasks', and the constraints 'by task ID' and 'up to 100'. This distinguishes it from the sibling tool 'get_task' which is for single tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch queries but does not explicitly mention when not to use it (e.g., for single tasks use 'get_task') or alternatives. No guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query Tripo account credit usage history by task.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| records | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions 'query' (suggesting read-only) and does not disclose auth needs, rate limits, or return format, though an output schema exists. Minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 8-word sentence conveys the purpose efficiently with no unnecessary words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema available, the description is adequate for a simple query tool. It could mention that it lists usage per task, but it is sufficiently complete for straightforward usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description adds value by clarifying the scope (no filtering needed). Baseline is 4, and the description confirms there are no parameters to configure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Query Tripo account credit usage history by task' clearly states a specific verb and resource, distinguishing it from related tools like get_balance (balance) and get_task (task status). However, it does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any when-not or exclusions. The description only states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 3D model from a reference image. Provide a local file path or public URL. This is an async operation — use task_status to poll progress and download_model to retrieve the result.
| Name | Required | Description | Default |
|---|---|---|---|
| pbr | No | Enable PBR materials. When true, Tripo will also enable texture output | |
| quad | No | Generate quad mesh output when supported | |
| texture | No | Enable texturing. Set false to request a base model without textures | |
| autoSize | No | Automatically scale the model to real-world dimensions in meters | |
| compress | No | Compression mode. Set to geometry to request geometry compression | |
| exportUV | No | Control whether UV unwrapping is performed during generation | |
| imageUrl | No | Public URL of the reference image. Mutually exclusive with imagePath | |
| faceLimit | No | Target polygon face count | |
| imagePath | No | Local file path to the reference image. Mutually exclusive with imageUrl | |
| modelSeed | No | Optional seed for geometry generation | |
| orientation | No | Model orientation: default or align_image | |
| textureSeed | No | Optional seed for texture generation | |
| modelVersion | No | Model version (e.g. turbo, v3.0, v3.1, p1). Defaults to the latest supported H3 model | |
| smartLowPoly | No | Enable Tripo smart low-poly mesh optimization when supported | |
| generateParts | No | Generate semantic mesh parts when supported | |
| textureQuality | No | Texture quality: standard or detailed | |
| geometryQuality | No | Geometry detail mode for H3 models: standard or detailed | |
| textureAlignment | No | Texture alignment priority: original_image or geometry | |
| enableImageAutofix | No | Let Tripo optimize the reference image before generation |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses async nature and needing to poll/download, but omits details on destructive actions, auth, rate limits, or file handling specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences: purpose, input, async workflow. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. However, the description is ambiguous about whether local file path refers to an uploaded file or direct system access, leaving a gap for a tool with 19 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description only mentions providing a file path or URL, adding minimal extra meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 3D model from a reference image, distinguishing it from siblings like text_to_3d and image_to_multiview. It also specifies async behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (for generating 3D from image) and mentions async workflow with task_status and download_model. It lacks explicit 'when not to use' or alternatives among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate or edit an image from a source image using Tripo v3 image models.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Optional deterministic seed | |
| size | No | Optional output size string | |
| input | No | Image URL or file token. Mutually exclusive with imagePath and imageUrl | |
| model | No | Image model, for example seedream_v5, gemini-3-pro, or chat_image_2 | |
| width | No | Optional output width | |
| height | No | Optional output height | |
| prompt | No | Edit prompt | |
| imageUrl | No | Public image URL to use as input | |
| template | No | Optional image-generation template | |
| imagePath | No | Local image path to upload as input | |
| negativePrompt | No | What to avoid in the generated image |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks behavioral details such as whether editing modifies the source image or creates a new one, and doesn't clarify side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous words, front-loaded with action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and many optional parameters, the description does not explain usage of multiple input methods (input, imageUrl, imagePath) or mutual exclusivity, leaving gaps for a tool with 11 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented; description adds little beyond stating the source image context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states generate or edit an image from a source image using Tripo v3 models, distinguishing it from text-to-image and 3D generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 text_to_image or image_to_3d, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate front/left/back/right multiview reference images from a single source image.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | Image URL or file token. Mutually exclusive with imagePath and imageUrl | |
| imageUrl | No | Public image URL to use as input | |
| imagePath | No | Local image path to upload as input |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the generation action without disclosing limitations, computational cost, or required permissions. The existence of an output schema partially mitigates this but doesn't provide behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and result, zero waste. Concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with output schema and complete parameter docs, the description is adequate. However, given 28 siblings, more context on when to choose this over others would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the three parameters. The description adds no additional semantic value, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and resource 'multiview reference images' from a single source image, distinguishing it from siblings like image_to_3d or image_to_image. However, it could be more explicit about the specific output being front/left/back/right views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 multiview_to_3d or edit_multiview. The agent receives no context on prerequisites or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Gaussian Splat task from a source image.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | Image URL or file token. Mutually exclusive with imagePath and imageUrl | |
| imageUrl | No | Public image URL to use as input | |
| imagePath | No | Local image path to upload as input |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states that a task is generated but does not explain whether the operation is async, what permissions are needed, or what the response contains. The existence of an output schema partially mitigates this, but the description itself is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but borders on under-specification. It front-loads the key action but omits important details; it is adequate but not exceptional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 3D generation tasks and the lack of annotations, the description is incomplete. It does not explain what a 'Gaussian Splat task' entails, how to monitor task progress, or how the output is structured. The presence of an output schema does not fully compensate for the lack of contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description (e.g., 'Image URL or file token. Mutually exclusive with imagePath and imageUrl'). The tool description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and the resource ('a Gaussian Splat task from a source image'). While it specifies the output type, it does not differentiate from similar tools like 'image_to_3d', but the term 'Gaussian Splat' is specific enough to give a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'image_to_3d' or 'text_to_3d'). No prerequisites, context, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import an external model URL or file token into Tripo for downstream processing.
| Name | Required | Description | Default |
|---|---|---|---|
| input | No | Model file URL or file token. Mutually exclusive with filePath and fileUrl | |
| fileUrl | No | Public model URL to import | |
| filePath | No | Local model path to upload before import |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states 'import' but does not mention whether it creates a task, is synchronous, requires authentication, or has side effects. Lacks details on what happens after import.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded with the key action. No redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits key aspects like task creation, expected flow, or prerequisites. For a tool with no annotations, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add significant meaning beyond the schema; it merely paraphrases the purpose without clarifying parameter differences or usage constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'import' and resource 'external model URL or file token' into Tripo for downstream processing. It distinguishes from sibling tools by focusing on bringing in external models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 upload_file or create_model. The description does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in model catalog supported by this server with their capabilities. This is server metadata, not live discovery from Tripo.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| models | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adds 'server metadata, not live discovery' which clarifies scope; no further behavioral details needed for a simple listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, every sentence provides value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description fully covers the tool's functionality and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%; description is not required to add param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it lists the built-in model catalog with capabilities, and distinguishes from siblings by noting it is server metadata, not live discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when or when-not to use, but usage is implied for discovering available models; no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 3D model from 2-4 ordered reference images. Supply views in Tripo's expected order: front, left, back, right. This is an async operation — use task_status to poll progress and download_model to retrieve the result.
| Name | Required | Description | Default |
|---|---|---|---|
| pbr | No | Enable PBR materials. When true, Tripo will also enable texture output | |
| quad | No | Generate quad mesh output when supported | |
| taskId | No | Successful image_to_multiview or edit_multiview task ID to reuse directly. Mutually exclusive with imagePaths and imageUrls | |
| texture | No | Enable texturing. Set false to request a base model without textures | |
| autoSize | No | Automatically scale the model to real-world dimensions in meters | |
| compress | No | Compression mode. Set to geometry to request geometry compression | |
| exportUV | No | Control whether UV unwrapping is performed during generation | |
| faceLimit | No | Target polygon face count | |
| imageUrls | No | Public URLs for 2-4 ordered views. Supply them in Tripo's expected order: front, left, back, right. Mutually exclusive with imagePaths | |
| modelSeed | No | Optional seed for geometry generation | |
| imagePaths | No | Local file paths for 2-4 ordered views. Supply them in Tripo's expected order: front, left, back, right. Mutually exclusive with imageUrls | |
| orientation | No | Model orientation: default or align_image | |
| textureSeed | No | Optional seed for texture generation | |
| modelVersion | No | Model version (e.g. v3.0, v3.1, p1). Defaults to the latest supported H3 model | |
| smartLowPoly | No | Enable Tripo smart low-poly mesh optimization when supported | |
| generateParts | No | Generate semantic mesh parts when supported | |
| textureQuality | No | Texture quality: standard or detailed | |
| geometryQuality | No | Geometry detail mode for H3 models: standard or detailed | |
| textureAlignment | No | Texture alignment priority: original_image or geometry | |
| enableImageAutofix | No | Let Tripo optimize the ordered input views before generation |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the operation is asynchronous and instructs to use task_status for polling and download_model to retrieve results. This adds key behavioral context beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. First sentence states purpose, second gives critical input order constraint, third explains async workflow. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, async, result retrieval), the description covers core purpose, input constraints, and workflow. It does not detail optional parameters or output schema, but those are covered by schema and output schema. Slightly more context on follow-up steps would elevate it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 20 parameters. The description reinforces the image order constraint for imageUrls/imagePaths but adds no additional meaning beyond that. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 from 2-4 ordered reference images. It specifies the required view order (front, left, back, right) and distinguishes from siblings like image_to_3d or image_to_multiview by emphasizing the ordered multiview input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when 2-4 ordered images are available, but does not explicitly mention when not to use it (e.g., when a single image suffices, use image_to_3d). No alternatives are named, though the sibling tool list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refine an existing Tripo model task.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Task ID of the model to refine | |
| model | No | Optional refinement model version |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description is a single sentence without disclosing behavioral traits such as whether the tool creates a new task, requires credits, is asynchronous, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which under-specifies the tool. It is not appropriately sized for the complexity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (covers return values) but lack of workflow context, prerequisites, or explanation of what refinement does, the description is incomplete for an agent to understand when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters described). The description adds no extra meaning beyond what the schema already provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'refine an existing Tripo model task', which gives a verb and resource but lacks specificity on what refinement entails (e.g., quality improvement, detail addition). Compared to siblings like 'complete_mesh' or 'edit_multiview', it does not differentiate the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., when to refine vs complete a mesh). No context on prerequisites or expected outcomes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply one or more preset animations to a rigged model.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Rigged model task ID | |
| animation | No | Single preset animation identifier | |
| outFormat | No | Output format: glb or fbx | |
| animations | No | Multiple preset animation identifiers | |
| bakeAnimation | No | Bake animation into the model | |
| animateInPlace | No | Play animation in place without displacement | |
| exportWithGeometry | No | Export with geometry included |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not mention whether the operation is destructive, if it creates a new task, or any required model state. The schema hints at options like bakeAnimation and animateInPlace, but the description does not explain their behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. However, it could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and an output schema, the description is too brief. It does not explain the effect on the model, return value, or how to use multiple animations. The presence of an output schema does not fully compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no meaningful detail beyond what the schema provides, e.g., it does not explain the difference between 'animation' and 'animations' or what preset animation identifiers are available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Apply one or more preset animations to a rigged model' clearly states the action (apply) and the target (preset animations to rigged model), distinguishing it from sibling tools like rig_model or convert_format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites or conditions mentioned. The description does not provide usage context beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a lowpoly version of a generated 3D model. Supports quad mesh or triangle output. This is an async operation — use task_status to poll progress.
| Name | Required | Description | Default |
|---|---|---|---|
| bake | No | Bake textures into the decimated output when supported | |
| quad | No | Produce quad mesh instead of triangles | |
| model | No | Optional Tripo model/version to use for decimation | |
| partNames | No | Specific segmented part names to decimate | |
| targetFaces | No | Target face count for the lowpoly output | |
| originalTaskId | Yes | Task ID of the model to retopologize |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses async nature and polling requirement, but omits details on destructive behavior, permissions, rate limits, or impact on original model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the purpose, deliver key options, and mention async nature. No redundant or irrelevant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and async behavior, the description is minimal. It does not explain output (e.g., returns task ID), constraints (originalTaskId must be a generated model), or handling of partial failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds context only for the quad parameter (supports quad or triangle). No additional meaning for other parameters like originalTaskId, targetFaces, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates a lowpoly version of a generated 3D model, specifies quad or triangle output, and highlights asynchronous behavior. It effectively distinguishes from siblings like refine_model or convert_format through the async context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions using task_status for polling but does not explicitly state when to use this tool over alternatives (e.g., refine_model, segment_mesh). No exclusions or prerequisite guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a model can be rigged and get the recommended rig type.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Task ID, model URL, or file token to check |
| Name | Required | Description |
|---|---|---|
| reason | No | |
| rigType | No | |
| riggable | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. It implies idempotent read-only check, but doesn't mention side effects, costs, or error conditions. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with no wasted words. Efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. The description is sufficient for the simple check operation, though it could offer more context about the relationship with 'rig_model'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description already covers the single parameter (Task ID, model URL, or file token) with 100% coverage. Description adds no extra meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'check' and the resource 'model riggability' and 'recommended rig type'. It effectively distinguishes from sibling tool 'rig_model' which applies the rig.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'rig_model'. Lacks explicit context about prerequisites or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Automatically rig a model for animation.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | No | Skeleton specification: tripo or mixamo | |
| input | Yes | Task ID, model URL, or file token to rig | |
| model | No | Rigging model: rig-v2.0 or rig-v1.0 | |
| rigType | No | Rig type such as biped, quadruped, hexapod, octopod, avian, serpentine, or aquatic | |
| outFormat | No | Output format: glb or fbx |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It fails to disclose behavioral traits like side effects (modifies the model), permissions needed, or process duration. The term 'automatically' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It doesn't earn its place as it could include more helpful details without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters) and the existence of an output schema, the description is too brief. It doesn't explain the workflow, output format, or any constraints, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description doesn't need to add parameter info. It adds no extra meaning beyond what the schema already provides. A neutral score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to automatically rig a model for animation. It distinguishes this tool from siblings like 'rig_check' and 'retarget_animation' by specifying automation and the target outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't specify prerequisites (e.g., model must be imported) or exclusions (e.g., not for already-rigged models).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Segment a model into editable parts.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Task ID, model URL, or file token to segment | |
| model | No | Optional segmentation model version |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not mention whether the operation is destructive, required permissions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundancy, front-loaded with key action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity and an output schema, the description is too brief. Missing context about input types, expected behavior, and when to choose this over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Segment') and resource ('model') with a clear outcome ('editable parts'). It distinguishes from general editing but not from similar siblings like retopologize or refine_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. No prerequisites, context, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a stylization effect to a generated 3D model (lego, voxel, voronoi, minecraft). This is an async operation — use task_status to poll progress, then download_model to retrieve the stylized model.
| Name | Required | Description | Default |
|---|---|---|---|
| style | Yes | Stylization style: lego, voxel, voronoi, or minecraft | |
| blockSize | No | Optional block size for minecraft style | |
| originalTaskId | Yes | Task ID of the model to stylize |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the async behavior and references the polling and retrieval workflow. No contradictions, but lacks details on side effects or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and then provides async workflow guidance. It is concise and to the point, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's async nature, multiple styles, and optional parameter, the description adequately covers purpose, flow, and linkages to sibling tools. An output schema exists but is not provided, but the description still offers sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description repeats the style parameter values and mentions blockSize as optional, but doesn't add significant meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a stylization effect to a 3D model, listing specific styles (lego, voxel, voronoi, minecraft). It distinguishes itself from siblings by emphasizing it's an async operation and directing to task_status 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it's an async operation and instructs the agent to poll progress with task_status and retrieve results with download_model. While it doesn't provide when-not-to-use or alternatives, it gives clear context for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an async 3D generation or post-processing task. Returns progress info and the current state, such as queued, running, success, failed, cancelled, or expired.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID from a previous generation or post-processing call |
| Name | Required | Description |
|---|---|---|
| type | No | |
| error | No | |
| output | No | |
| status | Yes | |
| taskId | Yes | |
| progress | Yes | |
| createdAt | No | |
| rawOutput | No | |
| completedAt | No | |
| creditsConsumed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that tool returns progress info and current state. For a simple read-only status check, this is sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no waste. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values are covered. Description is complete for a simple status check tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds context that taskId comes from a previous generation or post-processing call, which is helpful beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Check the status of an async 3D generation or post-processing task' with specific verb+resource. Distinguishes from sibling tools like get_task and get_tasks by emphasizing async tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage after starting a task, but does not explicitly state when to use versus alternatives like get_task or get_tasks. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a 3D model from a text prompt. This is an async operation — use task_status to poll progress and download_model to retrieve the result.
| Name | Required | Description | Default |
|---|---|---|---|
| pbr | No | Enable PBR materials. When true, Tripo will also enable texture output | |
| quad | No | Generate quad mesh output when supported | |
| prompt | Yes | Text description of the 3D model to generate | |
| texture | No | Enable texturing. Set false to request a base model without textures | |
| autoSize | No | Automatically scale the model to real-world dimensions in meters | |
| compress | No | Compression mode. Set to geometry to request geometry compression | |
| exportUV | No | Control whether UV unwrapping is performed during generation | |
| faceLimit | No | Target polygon face count | |
| imageSeed | No | Optional seed for prompt-to-image generation before 3D reconstruction | |
| modelSeed | No | Optional seed for geometry generation | |
| textureSeed | No | Optional seed for texture generation | |
| modelVersion | No | Model version (e.g. turbo, v3.0, v3.1, p1). Defaults to the latest supported H3 model | |
| smartLowPoly | No | Enable Tripo smart low-poly mesh optimization when supported | |
| generateParts | No | Generate semantic mesh parts when supported | |
| negativePrompt | No | What to avoid in the generation | |
| textureQuality | No | Texture quality: standard or detailed | |
| geometryQuality | No | Geometry detail mode for H3 models: standard or detailed |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the asynchronous nature, which is a key behavioral trait. However, it omits other behavioral details such as required permissions (if any), potential failure modes, or any side effects beyond the async workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that cover the core purpose and the essential async workflow. Every word adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters) and the existence of an output schema, the description adequately covers the main workflow (async generation). However, it could mention the output (e.g., 'Returns a task ID for polling') or provide a brief example of usage, but the output schema likely covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters with descriptions. The tool description adds no extra parameter information beyond what is in the schema. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate a 3D model') and the resource ('from a text prompt'). It also distinguishes itself by noting it's an async operation and points to related tools (task_status, download_model), making its purpose unmistakable even among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the async workflow (poll with task_status and retrieve with download_model), which is helpful context. However, it does not explicitly state when to use this tool versus alternatives like image_to_3d or multiview_to_3d, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt using Tripo v3 image-generation models.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Optional deterministic seed | |
| size | No | Optional output size string if supported by the selected image model | |
| model | No | Image model, for example seedream_v5, gemini-3-pro, or chat_image_2 | |
| width | No | Optional output width | |
| height | No | Optional output height | |
| prompt | Yes | Text prompt for image generation | |
| template | No | Optional Tripo image-generation template such as asset_extraction or t_pose | |
| negativePrompt | No | What to avoid in the generated image |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It fails to disclose behavioral aspects like output format, safety filters, rate limits, or side effects (e.g., file creation). Only mentions the model family.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise but lacks detail. While not verbose, it sacrifices informative value for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters (many optional) and an output schema, the description is incomplete. It does not explain the purpose of key parameters like model, size, width/height, negativePrompt, or template.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds no extra meaning beyond what's in the schema, hence baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate an image from a text prompt' with a specific verb and resource, and distinguishes from sibling tools like image_to_image which require an image input. It also specifies the model family (Tripo v3).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as image_to_image or text_to_3d. The description does not mention prerequisites, exclusions, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate or regenerate textures for an existing model.
| Name | Required | Description | Default |
|---|---|---|---|
| pbr | No | Enable PBR materials | |
| bake | No | Bake generated textures | |
| input | Yes | Task ID, model URL, or file token to texture | |
| model | No | Optional texture model version | |
| texture | No | Enable texture generation | |
| compress | No | Compress model geometry | |
| partNames | No | Specific segmented part names to texture | |
| styleImage | No | Style image URL or file token for texture generation | |
| textPrompt | No | Text prompt for texture generation | |
| imagePrompt | No | Image prompt URL or file token for texture generation | |
| textureSeed | No | Optional seed for texture generation | |
| textureQuality | No | Texture quality: standard, detailed, or extreme | |
| textureAlignment | No | Texture alignment priority: original_image or geometry |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| taskId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states 'generate or regenerate', omitting any details about whether textures are overwritten, required permissions, or asynchronous behavior. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks sufficient detail to be useful. While front-loaded, it does not fully earn its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (13 parameters, no annotations) and the presence of an output schema, the description is incomplete. It fails to explain how the input 'input' works, the possible outputs, or any prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 13 parameters have descriptions in the schema, so the description adds no additional meaning. The schema already covers semantics adequately, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates or regenerates textures for an existing model, which differentiates it from many sibling tools that handle other 3D operations. However, it could be more specific about the types of textures and what 'regenerate' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'stylize' or 'image_to_3d'. With 30 sibling tools, the absence of usage context forces the agent to infer from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local file to Tripo and return a reusable file token.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Local file path to upload to Tripo |
| Name | Required | Description |
|---|---|---|
| expiresIn | Yes | |
| fileToken | Yes | |
| presignedUrl | Yes |
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 mentions the return of a file token but does not disclose any behavioral traits such as file size limits, required permissions, whether it modifies state, error handling, or dependencies on other tools. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential information without unnecessary words. It is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects) and has an output schema (though not shown). The description covers the basic action and return value, but lacks details that would help an agent fully understand the tool's role, such as typical file types, relationship to other tools (e.g., 'create_file_upload'), or that the returned token is likely used in subsequent API calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, describing the 'filePath' parameter as 'Local file path to upload to Tripo'. The description adds no additional meaning beyond that, so the baseline of 3 is appropriate. There is no elaboration on path format, allowed extensions, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload a local file'), target ('to Tripo'), and outcome ('return a reusable file token'). It uses a specific verb and resource, making the purpose unambiguous. However, it does not differentiate from the sibling 'create_file_upload', which might have a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., file must exist, supported formats), or exclusions. The description simply states what it does without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0complete_meshconvert_format12 fields changedInput schema / properties / bakeAdded value: +{
+ "description": "Bake material textures during conversion",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / exportOrientationAdded value: +{
+ "description": "Target export orientation: +x, -x, +y, or -y. x_up and y_up are accepted as aliases",
+ "type": "string"
+}Input schema / properties / exportVertexColorsAdded value: +{
+ "description": "Export vertex colors when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / faceLimitAdded value: +{
+ "description": "Target face count for converted output",
+ "type": "integer"
+}Input schema / properties / fbxPresetAdded value: +{
+ "description": "FBX preset when exporting FBX, such as unity or unreal",
+ "type": "string"
+}Input schema / properties / packUVAdded value: +{
+ "description": "Pack UVs during conversion",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / partNamesAdded value: +{
+ "description": "Specific segmented part names to export",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Input schema / properties / pivotToCenterBottomAdded value: +{
+ "description": "Move pivot to the model center-bottom",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / quadAdded value: +{
+ "description": "Convert to quad mesh output when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / scaleFactorAdded value: +{
+ "description": "Scale multiplier for converted output",
+ "type": "number"
+}Input schema / properties / textureFormatAdded value: +{
+ "description": "Texture image format, such as png, jpg, or webp",
+ "type": "string"
+}Input schema / properties / textureSizeAdded value: +{
+ "description": "Target texture size for converted output",
+ "type": "integer"
+}create_file_uploadedit_multiviewget_balanceget_taskget_tasksget_usageimage_to_3d14 fields changedInput schema / properties / autoSizeAdded value: +{
+ "description": "Automatically scale the model to real-world dimensions in meters",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / compressAdded value: +{
+ "description": "Compression mode. Set to geometry to request geometry compression",
+ "type": "string"
+}Input schema / properties / enableImageAutofixAdded value: +{
+ "description": "Let Tripo optimize the reference image before generation",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / exportUVAdded value: +{
+ "description": "Control whether UV unwrapping is performed during generation",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / generatePartsAdded value: +{
+ "description": "Generate semantic mesh parts when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / geometryQualityAdded value: +{
+ "description": "Geometry detail mode for H3 models: standard or detailed",
+ "type": "string"
+}Input schema / properties / modelSeedAdded value: +{
+ "description": "Optional seed for geometry generation",
+ "type": [
+ "null",
+ "integer"
+ ]
+}Input schema / properties / modelVersion / descriptionPrevious value: -"Model version. Defaults to latest"New value: +"Model version (e.g. turbo, v3.0, v3.1, p1). Defaults to the latest supported H3 model"Input schema / properties / pbrAdded value: +{
+ "description": "Enable PBR materials. When true, Tripo will also enable texture output",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / quadAdded value: +{
+ "description": "Generate quad mesh output when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / smartLowPolyAdded value: +{
+ "description": "Enable Tripo smart low-poly mesh optimization when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / textureAdded value: +{
+ "description": "Enable texturing. Set false to request a base model without textures",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / textureAlignmentAdded value: +{
+ "description": "Texture alignment priority: original_image or geometry",
+ "type": "string"
+}Input schema / properties / textureSeedAdded value: +{
+ "description": "Optional seed for texture generation",
+ "type": [
+ "null",
+ "integer"
+ ]
+}image_to_imageimage_to_multiviewimage_to_splatimport_modellist_models3 fields changedOutput schema / properties / models / items / properties / aliasesAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}Output schema / properties / models / items / properties / defaultAdded value: +{
+ "type": "boolean"
+}Output schema / properties / models / items / properties / namespaceAdded value: +{
+ "type": "string"
+}multiview_to_3d19 fields changedInput schema / properties / autoSizeAdded value: +{
+ "description": "Automatically scale the model to real-world dimensions in meters",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / compressAdded value: +{
+ "description": "Compression mode. Set to geometry to request geometry compression",
+ "type": "string"
+}Input schema / properties / enableImageAutofixAdded value: +{
+ "description": "Let Tripo optimize the ordered input views before generation",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / exportUVAdded value: +{
+ "description": "Control whether UV unwrapping is performed during generation",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / generatePartsAdded value: +{
+ "description": "Generate semantic mesh parts when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / geometryQualityAdded value: +{
+ "description": "Geometry detail mode for H3 models: standard or detailed",
+ "type": "string"
+}Input schema / properties / imagePaths / descriptionPrevious value: -"Local file paths to 2-4 reference images from different angles. Mutually exclusive with imageUrls"New value: +"Local file paths for 2-4 ordered views. Supply them in Tripo's expected order: front, left, back, right. Mutually exclusive with imageUrls"Input schema / properties / imageUrls / descriptionPrevious value: -"Public URLs for 2-4 reference images from different angles. Mutually exclusive with imagePaths"New value: +"Public URLs for 2-4 ordered views. Supply them in Tripo's expected order: front, left, back, right. Mutually exclusive with imagePaths"Input schema / properties / modelSeedAdded value: +{
+ "description": "Optional seed for geometry generation",
+ "type": [
+ "null",
+ "integer"
+ ]
+}Input schema / properties / modelVersion / descriptionPrevious value: -"Model version. Defaults to latest"New value: +"Model version (e.g. v3.0, v3.1, p1). Defaults to the latest supported H3 model"Input schema / properties / orientationAdded value: +{
+ "description": "Model orientation: default or align_image",
+ "type": "string"
+}Input schema / properties / pbrAdded value: +{
+ "description": "Enable PBR materials. When true, Tripo will also enable texture output",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / quadAdded value: +{
+ "description": "Generate quad mesh output when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / smartLowPolyAdded value: +{
+ "description": "Enable Tripo smart low-poly mesh optimization when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / taskIdAdded value: +{
+ "description": "Successful image_to_multiview or edit_multiview task ID to reuse directly. Mutually exclusive with imagePaths and imageUrls",
+ "type": "string"
+}Input schema / properties / textureAdded value: +{
+ "description": "Enable texturing. Set false to request a base model without textures",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / textureAlignmentAdded value: +{
+ "description": "Texture alignment priority: original_image or geometry",
+ "type": "string"
+}Input schema / properties / textureQualityAdded value: +{
+ "description": "Texture quality: standard or detailed",
+ "type": "string"
+}Input schema / properties / textureSeedAdded value: +{
+ "description": "Optional seed for texture generation",
+ "type": [
+ "null",
+ "integer"
+ ]
+}refine_modelretarget_animationretopologize3 fields changedInput schema / properties / bakeAdded value: +{
+ "description": "Bake textures into the decimated output when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / modelAdded value: +{
+ "description": "Optional Tripo model/version to use for decimation",
+ "type": "string"
+}Input schema / properties / partNamesAdded value: +{
+ "description": "Specific segmented part names to decimate",
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+}rig_checkrig_modelsegment_meshstylize1 field changedInput schema / properties / blockSizeAdded value: +{
+ "description": "Optional block size for minecraft style",
+ "type": "integer"
+}task_status6 fields changedOutput schema / properties / completedAtAdded value: +{
+ "type": "string"
+}Output schema / properties / createdAtAdded value: +{
+ "type": "string"
+}Output schema / properties / creditsConsumedAdded value: +{
+ "type": "number"
+}Output schema / properties / outputAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "baseModelUrl": {
+ "type": "string"
+ },
+ "extra": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "imageUrl": {
+ "type": "string"
+ },
+ "imageUrls": {
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+ },
+ "modelUrl": {
+ "type": "string"
+ },
+ "modelUrls": {
+ "items": {
+ "type": "string"
+ },
+ "type": [
+ "null",
+ "array"
+ ]
+ },
+ "pbrModelUrl": {
+ "type": "string"
+ },
+ "renderedImageUrl": {
+ "type": "string"
+ }
+ },
+ "type": [
+ "null",
+ "object"
+ ]
+}Output schema / properties / rawOutputAdded value: +{
+ "additionalProperties": true,
+ "type": "object"
+}Output schema / properties / typeAdded value: +{
+ "type": "string"
+}text_to_3d14 fields changedInput schema / properties / autoSizeAdded value: +{
+ "description": "Automatically scale the model to real-world dimensions in meters",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / compressAdded value: +{
+ "description": "Compression mode. Set to geometry to request geometry compression",
+ "type": "string"
+}Input schema / properties / exportUVAdded value: +{
+ "description": "Control whether UV unwrapping is performed during generation",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / generatePartsAdded value: +{
+ "description": "Generate semantic mesh parts when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / geometryQualityAdded value: +{
+ "description": "Geometry detail mode for H3 models: standard or detailed",
+ "type": "string"
+}Input schema / properties / imageSeedAdded value: +{
+ "description": "Optional seed for prompt-to-image generation before 3D reconstruction",
+ "type": [
+ "null",
+ "integer"
+ ]
+}Input schema / properties / modelSeedAdded value: +{
+ "description": "Optional seed for geometry generation",
+ "type": [
+ "null",
+ "integer"
+ ]
+}Input schema / properties / modelVersion / descriptionPrevious value: -"Model version (e.g. v2.5, v3.0, v3.1). Defaults to latest"New value: +"Model version (e.g. turbo, v3.0, v3.1, p1). Defaults to the latest supported H3 model"Input schema / properties / pbrAdded value: +{
+ "description": "Enable PBR materials. When true, Tripo will also enable texture output",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / quadAdded value: +{
+ "description": "Generate quad mesh output when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / smartLowPolyAdded value: +{
+ "description": "Enable Tripo smart low-poly mesh optimization when supported",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / textureAdded value: +{
+ "description": "Enable texturing. Set false to request a base model without textures",
+ "type": [
+ "null",
+ "boolean"
+ ]
+}Input schema / properties / textureQualityAdded value: +{
+ "description": "Texture quality: standard or detailed",
+ "type": "string"
+}Input schema / properties / textureSeedAdded value: +{
+ "description": "Optional seed for texture generation",
+ "type": [
+ "null",
+ "integer"
+ ]
+}text_to_imagetexture_modelupload_fileconvert_formatdownload_modelget_configimage_to_3dlist_modelsmultiview_to_3dretopologizestylizetask_statustext_to_3dScored across 29 tools
Each tool targets a distinct operation: generation, post-processing, file handling, or account queries. No two tools have overlapping purposes; even similar operations like image_to_3d and text_to_3d are clearly differentiated by input type.
Tool names follow a consistent snake_case verb_noun pattern (e.g., complete_mesh, download_model). Some names use 'to' for conversion (e.g., image_to_3d), which is a slight deviation but still predictable and clear.
With 29 tools, the server covers a broad range of 3D generation and post-processing tasks. While on the higher side, each tool serves a specific need, and the count is appropriate for the domain's complexity.
The tool surface covers the full lifecycle: generation (text, image, multiview), post-processing (refine, retopologize, rig, animate, texture, stylize, segment), file operations (upload, download, convert), and account queries (balance, usage). Missing deletion operations, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloud Blender for AI agents: scenes, assets, renders, MP4, STL, GLB — over hosted remote MCP.
MCP server for Qwen Image 3 AI image generation
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
MCP server for Hailuo (MiniMax) AI video generation