Skip to main content
Glama
naab007

BlenderMCP

by naab007
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

load_img_to_3d_model

Load the TripoSR image-to-3D inference server to enable converting images into 3D models. This initializes the model in memory, allowing subsequent image-to-3D operations.

Instructions

Start the local image-to-3D inference server (TripoSR). The server process is kept running until unload_img_to_3d_model() is called. Frees VRAM when unloaded — load only when you need it.

Parameters:

  • model_dir: Path to TripoSR weights directory (uses IMG_TO_3D_MODEL_DIR env var if omitted)

  • timeout: Seconds to wait for the server to come up (default 600; the first run downloads the weights). Its console output goes to img_to_3d_server.log in the temp folder.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeoutNo
model_dirNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.6.0
    • addedInput schema / properties / timeout
      Added value: +{
+  "default": 600,
+  "title": "Timeout",
+  "type": "number"
+}
  2. First observedv1.5.5

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden of behavioral disclosure, and it does so thoroughly: it mentions server persistence, VRAM deallocation on unload, first-run weight downloads, model_dir environment fallback, timeout semantics, and where console output goes. These are exactly the side effects an agent needs to predict before calling.

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 main action is front-loaded in one sentence, the lifecycle/VRAM caveat follows immediately, and the parameter explanations are compact and scannable. Every sentence contributes operational value with no filler.

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

Completeness4/5

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

For a simple start-server tool with no annotations and no output schema, the description covers purpose, parameters, side effects, and cleanup. It could clarify what happens when called while the server is already running and what the function returns, but those are minor given the tool's clear role.

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

Parameters5/5

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

The input schema only provides parameter names, types, and defaults (0% schema description coverage). The description adds real meaning: model_dir points to TripoSR weights and falls back to an environment variable, timeout controls how long to wait for startup, and the first run downloads weights. This fully compensates for the bare 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 opens with a specific verb and resource: 'Start the local image-to-3D inference server (TripoSR).' It clarifies that 'load' means starting a server, not directly loading an image, and it references the paired unload sibling, which helps distinguish it from the many other image-to-3D tools.

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 clear lifecycle context: the server stays running until unload_img_to_3d_model() is called, and the VRAM note tells the agent to invoke it only when needed. It does not explicitly compare against sibling generation tools like generate_hyper3d_model_via_images or generate_3d_from_image, so it stops short of full alternative routing.

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

Deploy Server

Other Tools