Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

audit_fork_refs

Destructive

Detect fork assets whose internal references still target the original source tree, then optionally remap each source object to its same-named fork counterpart.

Instructions

Audit a fork subtree for references that still point at the SOURCE tree it was copied from (duplicate_asset / duplicate_directory by script do NOT remap internal refs, so a copy keeps pointing at the original -- e.g. a MaterialInstance Parent still under /Game/VendorPack). Reports, per fork asset, the source dependencies (authoritative, from the AssetRegistry) and, best-effort, the exact PROPERTY holding each source object ref. With fix=true it FArchiveReplaceObjectRefs each source object to a same-named counterpart found inside the fork and saves the asset.

Returns: { fork_root: string, source_root: string, fix: bool, dependency_type: string, assets_scanned: int, offending_count: int, total_source_dependencies: int, offenders: [{asset, package, source_dependencies:[string], properties:[{property, ref}], remapped:int}], fixed_assets: int, refs_remapped: int, unresolved_counterparts: [string], message: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fixNoOptional bool (default false). Remap source object refs to a same-named fork counterpart via FArchiveReplaceObjectRef and save the asset.
fork_rootYesFork content path to audit, e.g. '/Game/MyGame/Environment/AutoLandscape'.
max_assetsNoMax fork assets to scan (optional, default 2000; clamped 1..20000).
source_rootNoOrigin tree the refs should not point at (optional; defaults to the project's Read Only Content Root when exactly one is configured).
dependency_typeNoOptional string, one of "hard"|"soft"|"all" (case-insensitive, default "all"). Scopes the per-asset dependency scan: "hard" surfaces only load-bearing refs into source_root (e.g. a MaterialInstance Parent, a hard object property) -- the correctness-critical case this audit exists for; "soft" surfaces only soft/lazy refs (TSoftObjectPtr, FSoftObjectPath); "all" (default) leaves the scan unscoped.
include_propertiesNoOptional bool (default true). Load each offending asset and report which property holds each source ref (best-effort; the dependency list is authoritative).

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?

Annotations mark it destructive/non-read-only/idempotent-false, and the description confirms the mutation path: with fix=true it FArchiveReplaceObjectRefs each source object to a same-named counterpart and saves the asset. It also discloses that the dependency list is authoritative while property attribution is best-effort, and reports unresolved counterparts.

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?

It front-loads the purpose and lead-in cause before parameters and return shape, and every sentence carries information. The inline Returns block is large but justified given there is no output schema, though it slightly bloats an otherwise tight description.

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 six-parameter tool with no output schema, the description covers the reason the tool exists, the fix semantics, the authoritative-vs-best-effort distinction, and a full return shape including offenders and unresolved_counterparts. Nothing an agent needs to invoke it correctly is 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 fix, fork_root, max_assets, source_root, dependency_type and include_properties. The description paraphrases fix and dependency_type but adds little syntax or edge-case detail beyond the schema text; baseline 3 applies.

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 states a specific verb (audit) and resource (a fork subtree's references to its source tree) and explains the underlying cause: duplicate_asset/duplicate_directory do not remap internal refs. It is clearly distinguishable from sibling diagnostics like get_asset_dependencies or audit_asset_references.

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 gives clear context for when the audit matters (post-duplicate forks that still point at the original, e.g. a MaterialInstance Parent under /Game/VendorPack) and notes that 'hard' scoping is 'the correctness-critical case this audit exists for'. It does not explicitly name an alternative tool to use for non-fork dependency questions, so it stops short of a 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