trident-mcp

Overview Schema Source Related Servers Discussions Admin

import_model

Destructive

Import an existing mesh (GLB, GLTF, FBX, OBJ, STL; up to 150 MB) to create a Tripo task and get a task_id for other operations.

Instructions

Import an existing mesh (GLB, GLTF, FBX, OBJ, STL; up to 150 MB) so other operations can use it by task ID. Creates a Tripo task (spends credits) and returns its task_id immediately; then call wait_for_task.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "input": "<input>"
    },
    "name": "import_model"
  }
}

Input Schema

Name	Required	Description	Default
`input`	Yes	The mesh: local path (GLB, FBX, OBJ, STL), URL (GLTF only as a URL) or file token. Up to 150 MB

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv0.4.0Oct 19, 2026

removedInput schema / properties / filePath

Removed value: -{
-  "description": "Local model path to upload before import",
-  "type": "string"
-}

removedInput schema / properties / fileUrl

Removed value: -{
-  "description": "Public model URL to import",
-  "type": "string"
-}

changedInput schema / properties / input / description

Previous value: -"Model file URL or file token. Mutually exclusive with filePath and fileUrl"New value: +"The mesh: local path (GLB, FBX, OBJ, STL), URL (GLTF only as a URL) or file token. Up to 150 MB"

addedInput schema / required
```
Added value: +[
+  "input"
+]
```
addedOutput schema / properties / model
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / operation
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / produces
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / status

Removed value: -{
-  "type": "string"
-}

removedOutput schema / properties / taskId

Removed value: -{
-  "type": "string"
-}

addedOutput schema / properties / task_id
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / warnings

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "taskId",
-  "status"
-]New value: +[
+  "task_id",
+  "operation",
+  "produces"
+]

Addedv0.3.0Jul 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare non-read-only, destructive, open-world, non-idempotent behavior. The description adds behavior the annotations cannot convey: that credits are consumed and that the operation is asynchronous with an immediate task_id return requiring a follow-up wait_for_task call. This is genuine additive context, though it says nothing about failure modes or credit costs when an import is rejected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler. The capability and formats come first, the cost + async contract second — properly front-loaded and every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not describe return values, yet it still explains the async pattern and the required follow-up call. Annotations cover the mutation/safety profile and the single parameter is fully documented, so nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single parameter, so the baseline is 3 per the rubric. The description slightly exceeds that by clarifying the accepted input forms (local path, URL with GLTF-only restriction) and reasserting the 150 MB cap in the context of the whole tool, reinforcing rather than purely duplicating the schema.

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

Purpose5/5

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

The description pairs a specific verb (import) with a specific resource (an existing mesh), enumerates the accepted formats, caps the size at 150 MB, and states the resulting artifact (a task ID usable by other operations). This cleanly separates it from siblings like convert_model, upload_file, and the *_to_model generators.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit workflow guidance — the call is asynchronous, returns task_id immediately, and the agent should then call wait_for_task — plus a cost warning about credits. It does not, however, contrast this tool against nearby alternatives (e.g., convert_model for changing format, upload_file for staging files), so the when-not case is left implicit.

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