Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

compare_objects

Read-onlyIdempotent

Diffs two live Unreal Engine objects in the same world property by property with engine equality, separating real differences from FText localization and outer noise.

Instructions

Diff TWO LIVE objects property by property at the same instant, using the ENGINE's own equality (FProperty::Identical + PPF_DeepComparison) rather than exported text, so FText localization identity and object-outer differences are classified as noise instead of being reported as real differences. Use it for "instance vs its CDO", "fork vs original", "this actor vs that one". Accepts world, which resolves BOTH paths in the SAME world (e.g. two live actors inside the server world); to compare the same actor ACROSS worlds — server vs client — use snapshot_object + diff_object_snapshots, which is what a replication check needs. list_instance_overrides diffs a placed actor against its archetype and also tells you which package carries the override; diff_blueprints diffs the AUTHORED graphs instead of live values.

Returns: { object_path_1: string, object_path_2: string, same_class: bool, same_type: bool, equality_predicate: string, differences: [{property, difference, kind, value_1?: typed_value, value_2?: typed_value, export_text_1?, export_text_2?, note?}], difference_count: int, noise_counts: object, noise_count: int, noise?: [...], world: string, world_name: string|null, world_package: string|null, world_type: string|null, net_mode: string|null, pie_instance: number }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
worldNoOptional world selector applied to BOTH paths: absent/'editor' (default) | 'pie' (ambiguous: PlayWorld, else the first PIE context) | 'server' (the PIE world with authority) | 'client' | 'pie:N' | 'game' (alias of 'pie'). It cannot straddle two worlds — one selector, both objects; an UNRECOGNIZED value is an error naming the worlds that exist, never a silent fallback.
include_noiseNoOptional (default false). With equality_predicate='identical', also emit under `noise[]` the properties the engine considers EQUAL but whose exported text differs (FText localization identity, object outer). They are ALWAYS counted in `noise_counts` whether or not this is set.
object_path_1YesPath or name of the first object (full object path, asset path, CDO/archetype, or dotted "Actor[.Component[.Subobject]]" by internal name; in a live world the first segment also matches the editor LABEL)
object_path_2YesPath or name of the second object, same resolution as object_path_1 and in the SAME world
equality_predicateNoOptional 'identical' (DEFAULT, FProperty::Identical + PPF_DeepComparison — what the engine itself calls equal) or 'export_text' (raw ExportTextItem_Direct(Defaults=nullptr, PPF_None) string compare, kept only for callers that depend on its over-reporting behavior).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial behavior beyond them: how noise is classified (FText localization identity, object outer), that noise is always counted regardless of include_noise, and that an unrecognized world selector is a hard error rather than a silent fallback. It also discloses the full return shape, which is otherwise unmodeled.

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?

Purpose, scope, and alternatives are front-loaded in the opening sentence, and the world/predicate caveats follow logically. The Returns block is verbose, but since there is no output schema it carries real informational weight, so the length is largely justified.

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 complex diff tool with no output schema and five parameters, the description covers purpose, alternatives, world-resolution constraints, predicate choice, noise semantics, and the full return payload. 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 100%, so the baseline is 3, but the description adds conceptual meaning the schema does not: it explains why 'identical' is preferred over 'export_text' (over-reporting) and stresses that the single world selector applies to BOTH paths and cannot straddle two worlds. This exceeds the baseline even though the per-parameter text already lives in 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 opens with a specific verb+resource ('Diff TWO LIVE objects property by property at the same instant') and immediately names the engine mechanism (FProperty::Identical + PPF_DeepComparison) that distinguishes it. It explicitly separates itself from snapshot_object/diff_object_snapshots, list_instance_overrides, and diff_blueprints, so an agent can pick it without opening a schema.

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

Usage Guidelines5/5

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

It gives concrete use cases ('instance vs its CDO', 'fork vs original', 'this actor vs that one'), states the world-scoping precondition, and routes cross-world comparisons to snapshot_object + diff_object_snapshots with an explicit reason ('what a replication check needs'). Alternatives are named with the condition that selects each.

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