Skip to main content
Glama

get_blueprint_scs_tree

Read-onlyIdempotent

Enumerate a Blueprint's full component tree, including native CDO, own SCS, and inherited ancestor components; filter by class or subclass across all sources.

Instructions

Enumerate the COMPLETE component tree of a Blueprint asset -- native components from the C++ CDO, its own SCS nodes, and everything inherited down the ancestor chain -- each classified by source with its class, attach parent/socket and transform, most-derived-wins. The component listing to use by default: get_blueprint_components_list sees ONLY the Blueprint's own SCS and silently omits native and inherited ones. component_class filters by class OR ANY SUBCLASS across all three sources, which Actor::GetComponentsByClass cannot do (it only ever sees a constructed instance's OwnedComponents, never SCS templates on a Blueprint nobody instantiated). WARNING: before concluding a component does not exist, read omitted_total, NOT results_truncated: null templates and name-shadowed ancestor entries are dropped without setting it, and omitted_duplicate_names[]/omitted_null_templates[] name what disappeared (counted before the component_class filter). scs_cdo_desync / generated_property_exists flag an SCS that disagrees with the compiled class -- the fingerprint of a half-reverted asset. See diff_blueprint_components to compare two trees, get_actor_components for a live instance.

Returns: { blueprint_name: string, blueprint_path: string, blueprint_valid: bool, parent_class: string, parent_class_path: string, components: [object], components_count: int, counts: object, has_simple_construction_script: bool, results_truncated: bool, max_results: int, component_class_filter: string|null, component_class_resolved: bool, desync_count: int, blueprint_status: string, generated_class_available: bool, omitted_duplicate_names: [{name, source, owner_class, shadowed_by?}], omitted_duplicate_count: int, omitted_null_templates: [{name, source, owner_class}], omitted_null_template_count: int, omitted_total: int } -- each component record also carries generated_property_exists (bool|null) and scs_cdo_desync (bool|null): the compiler mints one FObjectProperty per SCS node with the SAME FName as the node (SCS_Node.h, KismetCompiler.cpp), so a MISSING property means the SCS and the compiled class disagree -- the fingerprint of an asset left half-reverted. This tool emits Node->GetVariableName() VERBATIM; it does NOT normalize a trailing digit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_resultsNoCap on components returned, 1..10000 (default 1000)
blueprint_nameNoBlueprint or AnimBlueprint asset short name (exact) or full /Game path; an ambiguous bare name resolves to one match without saying which, so pass the path when it matters
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
include_nativeNoInclude C++/native components from the CDO (default true)
component_classNoOptional class filter (short name, /Script/Module.Class, or /Game/... Blueprint path). Matches this class OR ANY SUBCLASS of it (same semantics as the engine's own GetComponentsByClass), evaluated against every source (native CDO, own SCS, inherited SCS) -- unlike Actor::GetComponentsByClass/K2_GetComponentsByClass, which only ever see a live actor's already-constructed OwnedComponents and are blind to SCS node templates on a Blueprint that hasn't been instantiated yet.
include_inheritedNoInclude components inherited from ancestor Blueprint classes (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so safety and idempotency are covered structurally. The description nonetheless adds real value: the warning to read omitted_total rather than results_truncated before concluding absence, the disclosure that omitted_duplicate_names/omitted_null_templates are counted pre-filter, and the scs_cdo_desync/generated_property_exists desync flags. It stops short of nothing material, but annotations carry much of the burden here.

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 routing, then warnings, then an explicit Returns block — a logical progression. The main cost is redundancy: the compiler-minted FObjectProperty / 'fingerprint of a half-reverted asset' concept is explained in both the prose and the Returns section. Dense but most sentences earn their place for a tool this subtle.

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?

There is no output schema, so the description carries the full return-shape burden — and it does, enumerating every field, the per-component flags, and the three parallel omission arrays. With six parameters, a truncation cap, and filter semantics, every piece an agent needs to call and interpret this correctly is present.

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 goes beyond the schema by spelling out that component_class matches the class OR ANY SUBCLASS across all three sources, and contrasts this with Actor::GetComponentsByClass being blind to SCS templates on an uninstantiated Blueprint. That contrast is partly mirrored in the schema but the framing adds interpretive value.

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?

Opens with a specific verb and resource — 'Enumerate the COMPLETE component tree of a Blueprint asset' — and immediately enumerates the three sources (native CDO, own SCS nodes, inherited). It distinguishes itself from the nearest sibling in the same breath by stating get_blueprint_components_list sees ONLY the Blueprint's own SCS. An agent can identify and separate this tool from siblings 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?

Explicitly designates itself as 'the component listing to use by default' and explains why the alternative under-reports. It also routes to two other siblings with conditions: diff_blueprint_components to compare two trees and get_actor_components for a live instance. When-to-use and alternatives are both stated, not implied.

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