Skip to main content
Glama

get_task_status

Check the status of a 3D model generation task to determine completion, failure, or progress, requiring multiple calls until final status is reached.

Instructions

Get the status of a 3D model generation task.

IMPORTANT: This tool checks the status of a task started by create_3d_model_from_text.
You may need to call this tool MULTIPLE TIMES until the task completes.

Typical workflow:
1. Call this tool with the task_id from create_3d_model_from_text
2. Check the status in the response:
   - If status is SUCCESS, the task is complete and you can use the pbr_model_url
   - If status is FAILED, CANCELLED, BANNED, or EXPIRED, the task failed
   - If status is anything else, the task is still in progress
3. If the task is still in progress, wait a moment and call this tool again

Args:
    task_id: The ID of the task to check (obtained from create_3d_model_from_text).

Returns:
    A dictionary containing the task status and other information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
task_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler function for the 'get_task_status' tool. It is decorated with @mcp.tool(), which registers it as an MCP tool. The function retrieves the status of a 3D model generation task from the Tripo API, handles different status outcomes, and returns a dictionary with status, progress, and relevant URLs or messages.
    async def get_task_status(task_id: str) -> Dict[str, Any]:
        """
        Get the status of a 3D model generation task.
    
        IMPORTANT: This tool checks the status of a task started by create_3d_model_from_text.
        You may need to call this tool MULTIPLE TIMES until the task completes.
    
        Typical workflow:
        1. Call this tool with the task_id from create_3d_model_from_text
        2. Check the status in the response:
           - If status is SUCCESS, the task is complete and you can use the pbr_model_url
           - If status is FAILED, CANCELLED, BANNED, or EXPIRED, the task failed
           - If status is anything else, the task is still in progress
        3. If the task is still in progress, wait a moment and call this tool again
    
        Args:
            task_id: The ID of the task to check (obtained from create_3d_model_from_text).
    
        Returns:
            A dictionary containing the task status and other information.
        """
        # Get the API key from environment variable
        # api_key = os.environ.get("TRIPO_API_KEY")
        get_blender_connection()
        api_key = _tripo_apikey
        if not api_key:
            raise ValueError(
                "It may take some more time to correctly re-enter the tripo function. You can first check the scene and then try the tripo function again later"
            )
    
        # Create the Tripo client
        async with TripoClient(api_key=api_key) as client:
            # Get task status
            task = await client.get_task(task_id)
    
            # Ensure task is not None
            if task is None:
                raise ValueError(
                    f"Failed to retrieve task information for task ID: {task_id}"
                )
    
            # Create result dictionary
            result = {
                "task_id": task_id,
                "status": str(task.status),
                "progress": task.progress,
            }
    
            # Add output fields if task is successful and output is available
            if task.status == TaskStatus.SUCCESS and task.output:
                result.update(
                    {
                        "base_model_url": task.output.base_model,
                        "model_url": task.output.model,
                        "pbr_model_url": task.output.pbr_model,
                        "rendered_image_url": task.output.rendered_image,
                        "message": "Task completed successfully! You can now use the pbr_model_url.",
                        "next_step": "Use the pbr_model_url to access the 3D model, download it through import_tripo_glb_model tool",
                    }
                )
    
                if not task.output.pbr_model:
                    result["warning"] = (
                        "Model generated but PBR model URL is not available."
                    )
            elif task.status == TaskStatus.SUCCESS:
                result["message"] = (
                    "Task completed successfully but no output data is available."
                )
                result["next_step"] = (
                    "Try creating a new model with a different description."
                )
            elif task.status in (
                TaskStatus.FAILED,
                TaskStatus.CANCELLED,
                TaskStatus.BANNED,
                TaskStatus.EXPIRED,
            ):
                result["message"] = f"Task failed with status: {task.status}"
                result["next_step"] = (
                    "Try creating a new model with a different description."
                )
            else:
                result["message"] = (
                    f"Task is still in progress. Current status: {task.status}, Progress: {task.progress}%"
                )
                result["next_step"] = (
                    "IMPORTANT: You must call get_task_status again with this task_id to continue checking progress."
                )
                result["wait_message"] = (
                    "3D model generation typically takes 3-5 minutes. Please be patient and keep checking."
                )
    
            return result
Behavior5/5

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 thoroughly explains the polling nature of the tool ('call this tool MULTIPLE TIMES'), status interpretation (SUCCESS, FAILED, etc.), typical response structure (pbr_model_url on success), and failure conditions. This goes well beyond what a basic description would cover.

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?

The description is efficiently structured with clear sections (purpose, important notes, workflow, args, returns). Every sentence adds value: the first states the purpose, the second clarifies dependency, the third explains polling behavior, and the workflow provides actionable steps. No redundant or verbose content.

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?

Given the tool's complexity (asynchronous task status checking), lack of annotations, and presence of an output schema, the description is highly complete. It covers purpose, usage, behavioral details, parameter semantics, and response interpretation. The output schema handles return structure, so the description appropriately focuses on operational context.

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 description coverage is 0%, so the description must compensate. It clearly explains the single parameter (task_id), its purpose ('to check'), and its source ('obtained from create_3d_model_from_text'). However, it doesn't specify the expected format or constraints of task_id (e.g., string pattern, length), leaving a minor gap.

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 clearly states the specific action ('Get the status') and resource ('a 3D model generation task'), distinguishing it from siblings like create_3d_model_from_text (which starts tasks) and get_object_info (which checks objects). It explicitly mentions the dependency on create_3d_model_from_text, avoiding confusion with other task-related tools.

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

Usage Guidelines5/5

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 (after create_3d_model_from_text, with the returned task_id) and when to call it repeatedly (until task completion). It outlines a complete workflow with status interpretation and alternatives for different outcomes, clearly differentiating it from other status-checking siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/VAST-AI-Research/tripo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server