Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

diff_blueprint_components

Read-onlyIdempotent

Compare two Blueprint component trees, or a Blueprint against a saved snapshot, to report added, removed, and changed components, including parent, socket, source, and transform changes.

Instructions

Compare the COMPONENT trees of two Blueprints (or of one Blueprint against a components[] array captured earlier from get_blueprint_scs_tree) and report which components were added, removed or changed, where "changed" means the class, attach_parent, attach_socket, source or relative transform (0.01 tolerance) differ. It reuses get_blueprint_scs_tree's full enumeration, so native + own SCS + inherited components are all in scope, most-derived-wins. Use it for "did a reparent or a merge lose a component?" -- feeding a pre-change scs_tree as components_b makes it a before/after check without a second asset. removed = in A only, added = in B only. Read-only. diff_blueprints covers components AND graphs AND variables; get_blueprint_component_overrides goes deeper into ONE component's per-property provenance.

Returns: { blueprint_a, a_path, blueprint_b, b_path, side_b_source, added:[record], removed:[record], changed:[{name, class, changes:{class?:{a,b}, attach_parent?:{a,b}, attach_socket?:{a,b}, source?:{a,b}, transform?:{a,b}}}], unchanged_count, counts_a:{native,scs,inherited}, counts_b:{...}, truncated, total_differences }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
blueprint_aYesFirst Blueprint asset path or short name (the "before" / baseline side).
blueprint_bNoSecond Blueprint (the "after" side). Omit if passing components_b.
max_resultsNoCap on components enumerated per live side, 1..10000 (default 2000).
components_bNoAlternative to blueprint_b: a prior get_blueprint_scs_tree components array (snapshot). A snapshot without transforms reads every transform as changed.
include_nativeNoInclude native/CDO components on the live side(s) (default true).
include_inheritedNoInclude components inherited from ancestor Blueprints (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/no-open-world, and the description restates 'Read-only' (redundant). However it adds real behavioral context beyond annotations: the 0.01 transform tolerance, most-derived-wins enumeration semantics, the native+own+inherited scope, and the caveat that a transform-less snapshot reads every transform as changed.

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?

The purpose and alternative-routing are front-loaded, and the Returns block substitutes for a missing output schema, so it earns its space. It is dense rather than padded, though slightly verbose.

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 six parameters and no output schema, the description covers enumeration scope, tolerance, snapshot caveats, sibling boundaries, and the full return shape. An agent has everything needed to call and interpret it correctly.

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. The description adds directional meaning the schema lacks: 'removed = in A only, added = in B only', and that components_b can substitute for blueprint_b as a captured baseline. max_results and the include_* flags are left to 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?

States a specific verb+resource: comparing the COMPONENT trees of two Blueprints. It explicitly distinguishes itself from siblings, noting diff_blueprints covers components AND graphs AND variables, and get_blueprint_component_overrides goes deeper into one component's provenance.

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?

Gives explicit when-to-use ('did a reparent or a merge lose a component?') and names the alternatives with the condition that selects them (diff_blueprints, get_blueprint_component_overrides). It also explains how to convert it into a before/after check via components_b without a second asset.

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