Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

migrate_assets

Destructive

Copy Unreal assets and their dependencies into another project's Content folder, skipping existing files and optionally ignoring dependencies.

Instructions

Copy assets, and their dependencies unless ignore_dependencies, into another project's Content folder with IAssetTools::MigratePackages, with no prompt and skipping files that already exist there. The engine first saves every dirty package of this editor, and migrates nothing if one of them fails to save. What was copied is measured from the migration's own package list against the disk: migrated lists each package written (dependencies included), skipped_existing the requested ones the destination already had, failed the requested ones neither written nor skipped. Succeeds when nothing requested failed. destination_path must be a Content folder with a .uproject (or one .uplugin) next to it, or the engine migrates nothing and the call fails.

Returns: { migrated_count: int, failed_count: int, requested_count: int, destination_path: string, ignore_dependencies: bool, migrated: [{ package: string, file: string }], skipped_existing: [string], failed: [string], note: string? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asset_pathsYesAsset object or package paths to migrate (e.g. ["/Game/Props/SM_Crate"]); each is reduced to its package name.
destination_pathYesTarget content folder, e.g. D:/OtherProject/Content
ignore_dependenciesNoWhen true only the listed packages are copied, without their dependencies (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • changedInput schema / properties / asset_paths / description
      Previous value: -"List of asset paths to migrate"New value: +"Asset object or package paths to migrate (e.g. [\"/Game/Props/SM_Crate\"]); each is reduced to its package name."
    • changedInput schema / properties / ignore_dependencies / description
      Previous value: -"If true, skip copying package dependencies"New value: +"When true only the listed packages are copied, without their dependencies (default false)."
  2. 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 past the annotations (destructiveHint=true, idempotentHint=false) by disclosing no-prompt execution, skip-if-already-exists semantics, the pre-save of every dirty package, the all-or-nothing abort when a save fails, and success criteria. Note a mild tension with idempotentHint=false since existing files are skipped, but the disclosed save side effects justify non-idempotent annotation, so this is not a contradiction.

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 the core action and outcome, and nearly every clause carries information the caller needs. It is dense and slightly run-on in the middle (the migrated/skipped_existing/failed explanation), but not padded.

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?

No output schema exists, and the description compensates by spelling out the full return shape (counts, arrays, optional note) plus failure semantics. For a destructive cross-project mutation tool, an agent has everything needed to call it 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 already 100%, so the baseline is 3, but the description adds real value beyond the schema: destination_path must resolve to a Content folder with a .uproject/.uplugin adjacent, and asset_paths are reduced to package names. That destination validation constraint is not present in the schema description.

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 (copy/migrate) and resource (assets plus dependencies) with explicit scope: into ANOTHER project's Content folder via IAssetTools::MigratePackages. That cross-project scope cleanly separates it from in-project siblings like move_asset, duplicate_asset and consolidate_assets.

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?

Gives clear preconditions for correct use (destination_path must be a Content folder with a .uproject or .uplugin beside it, otherwise nothing migrates and the call fails) and describes the ignore_dependencies switch. It does not name alternative tools for adjacent tasks such as exporting or in-project moving, so it stops short of full when/when-not routing.

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