Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

rename_asset

Destructive

Renames an Unreal Engine asset in place, blocking read-only roots and CDO hard references that would hang the editor or fail to save.

Instructions

Renames an asset to a new name in its current directory. GUARDED (both guards are shared with move_asset, and both come from the AssetRenameManager source -- see the comment block on AnyNativeCdoHardReferences): (1) refuses to touch anything under a read-only root (readonly_roots, default: the project's Read Only Content Roots -- the upstream tree is never mutated in place); (2) refuses BEFORE calling the engine when a native class' CDO hard-references the asset, because FAssetRenameManager would open an FMessageDialog there and block the game thread (which kills the MCP session). And it does not trust IAssetTools::RenameAssets' return value: the result is READ BACK (new object resolves + new package on disk + redirector left at the original path), because the engine silently drops packages that failed to save unless UE source control is connected (with plain git it never is).

Returns: { original_asset_path: string, new_asset_name: string, new_asset_path: string, rename_success: bool, rename_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 rename
new_asset_nameYesNew name for the asset
readonly_rootsNoOptional array of content roots that must never be written. 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.)
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. Set false to skip the scan (faster, but a modal can then hang the editor).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Far exceeds the destructiveHint=true annotation: it discloses the two guards, why the CDO guard exists (FMessageDialog would block the game thread and kill the session), and that IAssetTools::RenameAssets' return value is not trusted and results are read back. This is exactly the kind of pre-mutation context 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.

Conciseness3/5

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

Purpose is front-loaded, but the body is a dense wall of engine internals (FAssetRenameManager, AnyNativeCdoHardReferences comment block) plus a very long inline Returns type listing. Much of it earns its place given the absence of an output schema, but the paragraph is heavier than it needs to be for an agent.

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 and a mutation tool that has engine-side failure modes, the description compensates fully: it inlines the return shape, the guard behavior, and the read-back verification. Nothing an agent needs to invoke this correctly and interpret the result appears to be missing.

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 already 100% and each parameter carries its own description, so the baseline is 3. The description adds material meaning above that by explaining the read-only-root guard's default and the consequence of disabling check_cdo_references (a modal can hang the editor), giving the agent the cost/benefit of each flag.

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 (renames), resource (an asset), and scope (to a new name in its current directory), which cleanly separates it from move_asset. It also explicitly names move_asset as the sibling it shares guards with, so an agent can route between the two without opening schemas.

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

Usage Guidelines2/5

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

The description never says when to choose this tool versus alternatives such as bulk_rename_assets or move_asset. Guard conditions (read-only roots, CDO hard-references) describe refusal behavior at runtime, not the tool-selection decision an agent faces before calling it.

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