Skip to main content
Glama

import_asset

Destructive

Import an image from disk into an Unreal content folder as a Texture2D and return the created object path. Use it for image assets only; other file types need their dedicated import handlers.

Instructions

Import an IMAGE file from disk into a content folder as a Texture2D, driving the texture factory inline (it deliberately avoids IAssetTools::ImportAssets, which asserts when re-entered from the engine tick) and returning the created object path. It always overwrites an asset of the same name -- replace_existing is accepted and ignored. Images ONLY -- png/jpg/jpeg/bmp/tga/dds/exr/hdr/tif/tiff/psd/pcx: any other extension is a clean error naming the dedicated handler to use instead (import_texture_file for images, import_sound_file for .wav, import_landscape_heightmap for terrain, interchange_import_asset for FBX/glTF meshes). A missing source file or a destination that is not a /Game long path also errors before anything is touched.

Returns: { source_file_path: string, destination_path: string, imported_object_paths: [string] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
destination_pathYesUE long path of the target content folder, e.g. /Game/Imported. Must start with '/'.
replace_existingNoACCEPTED AND IGNORED: the tool reads this flag and never uses it. The underlying import suppresses the overwrite dialog and re-imports over an existing asset of the same name regardless of what you pass, so neither value changes anything.
source_file_pathYesAbsolute path to the image on disk; its existence is checked before any work starts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that existing same-name assets are always overwritten regardless of input, that `replace_existing` is read and ignored, that the import bypasses IAssetTools::ImportAssets due to an assert on re-entry from the engine tick, and exactly which preconditions (missing file, non-/Game destination) fail before anything is touched. Consistent with destructiveHint=true and idempotentHint=false.

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 with purpose, then constraints, then return shape — a sound ordering. It is dense but earns most of its length; the parenthetical about the internal IAssetTools assert is implementation trivia that does not help an agent decide or call correctly.

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 no output schema, the description carries the return contract itself ({ source_file_path, destination_path, imported_object_paths }) and covers overwrite behavior, accepted-format scope, and error preconditions. An agent has everything needed to call this correctly and interpret the result.

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% so the baseline is 3, but the description adds failure semantics the schema does not carry: an invalid destination that is not a /Game long path and a nonexistent source file both error before any work starts. It also reinforces that `replace_existing` is inert, which the schema already states.

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?

States a specific verb + resource + type constraint: import an IMAGE file from disk into a content folder as a Texture2D, plus the return payload. It distinguishes itself from sibling importers by explicitly enumerating the extensions it accepts and the sibling to use for everything else.

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?

Explicitly scopes the tool to images and names alternatives by format (import_sound_file for .wav, import_landscape_heightmap for terrain, interchange_import_asset for meshes), which is strong routing guidance. However the parenthetical "import_texture_file for images" is self-undermining since this tool is itself the image importer, leaving ambiguity about which of the two an agent should pick.

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