Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

move_asset

Destructive

Move an Unreal asset to a new folder while keeping its name, blocking read-only roots and CDO hard references, then verify the saved file and package.

Instructions

Moves an asset to a new folder while keeping its name. GUARDED exactly like rename_asset (it reaches the same FAssetRenameManager through UEditorAssetLibrary::RenameAsset): (1) read-only roots are refused -- and here BOTH ends are checked, source and destination, since a move can also drop an asset INTO the upstream tree; (2) a native CDO hard-reference makes it refuse before the engine can open its blocking modal; (3) the outcome is read back from memory+disk instead of trusting the returned bool, which stays true even when the new package failed to save (the engine only reacts to that when UE source control is connected).

Returns: { original_asset_path: string, new_folder_path: string, new_asset_path: string, move_success: bool, move_message: string, new_asset_class: string, new_package_name: string, asset_verified: bool, new_file_size_bytes: number?, new_file_size_mb: number?, original_file_exists: bool?, original_asset_class: string, original_package_name: string, new_object_resolves: bool?, new_file_on_disk: bool?, new_file_path: string?, redirector_left: bool?, verification: object?, verification_checks: [object]?, would_block_on_modal: bool?, cdo_referencing_class: string?, cdo_soft_reference_check: string? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asset_pathYesFull asset path to move
readonly_rootsNoOptional array of content roots that must never be written (checked on source AND destination). Absent => the project's Read Only Content Roots. An EXPLICIT [] disables the guard. (Read through mcp_common::ParseReadonlyRoots, so the type hint is what puts it in the catalog.)
new_folder_pathYesDestination folder path (e.g. /Game/NewFolder)
check_cdo_referencesNoOptional bool (default true). Scan native CDOs for a hard reference to the asset and refuse instead of letting the engine open a modal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Far exceeds the annotation bar (which only says destructive=true). It discloses three non-obvious traits: both source and destination are checked against read-only roots, a native CDO hard-reference triggers refusal before the engine modal opens, and the returned bool is untrustworthy so the outcome is re-verified from memory and disk. This is exactly the kind of non-structured behavior an agent needs.

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 numbered guard behaviors, then a labeled Returns block. It is long, but because no output schema exists the return enumeration is genuinely load-bearing rather than padding; only minor trimming is possible.

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?

For a destructive mutation with 4 params and no output schema, the description covers the guard model, failure modes, and the full return shape, and the provided Returns list substitutes for the missing output schema. Nothing an agent needs in order to call this safely appears to be missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents asset_path, new_folder_path, readonly_roots and check_cdo_references. The description reinforces the semantics of the guards (both-ends checking, modal avoidance) but adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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+scope ('Moves an asset to a new folder while keeping its name'), which cleanly distinguishes it from rename_asset and bulk_rename_assets. It also names the underlying engine path, so an agent knows exactly what operation this is.

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 explicitly frames itself against a named sibling ('GUARDED exactly like rename_asset') and the 'keeping its name' clause implicitly routes rename requests elsewhere. However, it never states an explicit when-to-use/when-not rule or names a full alternative for the rename case, so 4 rather than 5.

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