Unreal-MCP-Ghost

Overview Schema Source Related Servers Discussions Admin

import_texture

Import a texture file into UE5 Content Browser as a Texture2D asset. Supports PNG, JPG, TGA, EXR, HDR, and BMP with automatic compression settings based on filename.

Instructions

Import a texture file into UE5 Content Browser as a Texture2D asset.

Supports PNG, JPG/JPEG, TGA, EXR, HDR, and BMP formats. The file must already exist on the Windows machine running UE5.

When texture_type is "auto" (default) the correct compression settings and sRGB flag are inferred from the filename suffix: *_n / *_normal / *_nrm → TC_NORMALMAP, sRGB=False *_r / *_rough / *_m / *_metal *_ao / *_occlusion / *_orm *_mask → TC_MASKS, sRGB=False *_h / *_height / *_disp → TC_MASKS, sRGB=False *_e / *_emissive / *_emit → TC_DEFAULT, sRGB=True everything else (BaseColor…) → TC_DEFAULT, sRGB=True

Returns: JSON string with StructuredResult — outputs on success: { "success": true, "stage": "import_texture", "outputs": { "asset_path": "/Game/Textures/T_Wood_BaseColor", "asset_type": "Texture2D", "texture_type": "BaseColor", "srgb": true, "compression": "TC_DEFAULT" }, "warnings": [], "errors": [], "log_tail": [] } failure: {"success": false, "stage": "import_texture", "errors": [""]}

KB: see knowledge_base/31_GENERATIVE_CONTENT_PIPELINE.md#overview Example: import_texture(file_path="/Game/MCP_Test/Example")

Input Schema

TableJSON Schema

Name	Required	Default
`file_path`	Yes
`texture_type`	No	auto
`destination_path`	No	/Game/Textures/

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 20, 2026

TDQS

A4.8/5.0

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, and it does so thoroughly: it discloses supported formats, the requirement that the file exist on the UE5 machine, the auto-detection rules, and the exact return JSON structure for success and failure. It even provides an example call, making the tool's behavior fully transparent.

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 long but well-structured with clear sections (intro, formats, auto-detection, Args, Returns, KB, Example). Every sentence adds meaningful information; the auto-detection mapping is essential and not redundant. The main purpose is front-loaded.

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?

The description covers everything an agent needs: supported formats, file existence requirement, auto-detection rules, parameter defaults, return format with both success and failure examples, and a KB reference. It is complete for a tool of this complexity, especially with an output schema present.

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?

Since schema coverage is 0%, the description must fully explain parameters. It does: file_path is an absolute OS path with example, destination_path has a default and explains Content Browser folder, and texture_type is described with the full list of allowed values and override behavior. The auto-detection mapping adds extra value beyond 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 explicitly states 'Import a texture file into UE5 Content Browser as a Texture2D asset' with supported formats, clearly distinguishing it from mesh/sound import siblings. It is a specific verb+resource statement that leaves no ambiguity about the tool's function.

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?

The description provides clear context: file must exist on the Windows machine, and texture_type auto-detection logic is explained with filename suffix mappings. While it doesn't explicitly say 'use this for textures instead of import_static_mesh,' the scope is evident from the tool name and description, and the auto-detection guidance is detailed.

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

Deploy Server