Skip to main content
Glama

import_file

Import 3D files into Blender from FBX, OBJ, GLTF, USD, STL, and other formats. It auto-detects the format from the file extension when no type is specified.

Instructions

Import a 3D file into Blender.

Supports FBX, OBJ, GLTF/GLB, USD, STL, PLY, Alembic (ABC), Collada (DAE), SVG, and X3D formats. Auto-detects format from file extension if type is empty.

Args: filepath: Absolute path to the file to import. Must exist. type: Optional format override. One of: FBX, OBJ, GLTF, USD, STL, PLY, ABC, DAE, SVG, X3D. Auto-detected from extension if empty.

Returns: Dict with imported file path and format.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNo
filepathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.7.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / type / enum
      Added value: +[
      +  "ABC",
      +  "DAE",
      +  "FBX",
      +  "GLTF",
      +  "OBJ",
      +  "PLY",
      +  "STL",
      +  "SVG",
      +  "USD",
      +  "X3D"
      +]
  2. Changed1 schema field changedv1.2.2
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "import_fileDictOutput",
      +  "type": "object"
      +}
  3. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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 does disclose two useful behaviors — filepath must exist and format is auto-detected from extension — but says nothing about whether the import adds to or replaces the current scene, whether it is reversible, or any permission/state side effects of a mutation-style operation.

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

Conciseness4/5

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

Front-loaded purpose sentence followed by terse, well-organized format list, Args, and Returns sections. It is slightly longer than strictly needed given the format list repeats the schema enum, but every block is readable and earns its place.

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 2-parameter import tool with an output schema present, the description covers the operation, the parameters, and the detection fallback. The main omission is import side effects (scene state, overwrite behavior), which matters because no annotations exist to cover it.

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, and it does: `filepath` is described as an absolute path that must exist, and `type` is described as an optional override with the same enum values as the schema, plus the empty-string default semantics. Only deeper detail (e.g. case sensitivity, relative path handling) is missing.

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?

Opens with a specific verb + resource ('Import a 3D file into Blender') and names the full set of supported formats, which cleanly separates it from siblings like export_file, open_file, and create_object. An agent can identify the operation without opening the schema.

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

Usage Guidelines3/5

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

The description explains the format auto-detection behavior when `type` is empty, which is useful invocation context, but it never states when to reach for this tool versus export_file/open_file or what preconditions apply beyond 'must exist'. Usage is implied rather than directed.

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