Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

get_blueprint_component_property

Read-onlyIdempotent

Reads the effective default value of a property on a Blueprint component template, resolving inherited components without creating an override.

Instructions

Read the EFFECTIVE default of a property on a Blueprint component TEMPLATE, resolving components INHERITED from a parent/grandparent Blueprint. Read-only twin of set_blueprint_component_property: it NEVER mints an ICH override. Resolution order: own SCS template -> existing child InheritableComponentHandler override -> ancestor's declaring SCS template -> native CDO subobject. Omit property_name to dump ALL properties of the resolved template.

Returns: { blueprint_name: string, component_name: string, component_class: string, source: 'scs'|'inherited-ich'|'inherited-scs'|'inherited-native', resolved_from_class: string, property_name: string, value: any (single-property mode), properties: object, property_count: int (all-properties mode), duplicate_analysis?: { grouped_by, element_count, distinct_keys, duplicate_groups: [{key, count, indices[]}], empty_key_indices: [int], has_duplicates: bool, keys: [string] } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
property_nameNoProperty to read; omit to return ALL properties of the resolved template
blueprint_nameNoBlueprint asset path or short name
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
component_nameYesComponent variable name (own or inherited)
group_by_fieldNoOptional. Only with property_name pointing at a TArray of STRUCTS: group the elements by this struct member and report duplicate_groups[]/empty_key_indices[]/has_duplicates. Two elements sharing a key is invisible in a plain value dump, yet when that array feeds a TMap the LAST one silently wins (Map.Add overwrites) -- this is the guardrail for exactly that class of bug.
include_inheritedNoAlso resolve inherited/ICH/native components (default true); when false only this Blueprint's own SCS components are considered
report_duplicatesNoOptional bool. Implied true when group_by_field is given; pass true WITHOUT group_by_field to group by the WHOLE element value instead of one member.

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 already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: the full resolution precedence chain (own SCS -> child ICH override -> ancestor SCS -> native CDO) and the guarantee that it NEVER mints an ICH override. This is exactly the kind of non-obvious behavioral context an agent needs for a template-inheritance read.

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 purpose, then the twin relationship, resolution order, and the omission mode before the return shape. The Returns block is dense but each element earns its place given there is no output schema; the heavy ALL-caps emphasis is slightly noisy but the content is 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, but the description supplies a detailed returns contract covering both single-property and all-properties modes plus duplicate_analysis fields. Combined with full parameter coverage and the resolution order, an agent has everything needed to invoke and interpret it correctly.

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 all seven parameters and their meanings. The description largely restates what the schema provides (property_name omission behavior, mode outputs) rather than adding new syntax or constraints, so the baseline of 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?

States a specific verb+resource ('Read the EFFECTIVE default of a property on a Blueprint component TEMPLATE') and immediately qualifies the scope with inheritance resolution. It explicitly positions itself as the read-only twin of set_blueprint_component_property, letting an agent distinguish it from the setter sibling without opening either schema.

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?

Names the alternative (set_blueprint_component_property) and the condition that selects this tool over it ('read-only twin... NEVER mints an ICH override'). It also clarifies the omit-property_name mode. It does not explicitly state when-not-to-use versus other read siblings like get_blueprint_component_overrides, so it falls 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