Skip to main content
Glama

get_blueprint_parent

Read-onlyIdempotent

Read a Blueprint asset's parent class: its name, path, native C++ or Blueprint origin, and the asset type. Use it to inspect a Blueprint's direct inheritance before walking the full class chain.

Instructions

Read which class a Blueprint ASSET inherits from: parent class name and path, whether that parent is native C++ or another Blueprint, and the Blueprint's own type (Normal / Interface / MacroLibrary / FunctionLibrary / LevelScript / Const). The first question to ask about an unfamiliar Blueprint, and the way to tell whether a library class sneaked into the parent chain. It returns ONE level -- get_class_hierarchy walks the whole ancestor chain of the compiled class, get_blueprint_children lists descendants, and verify_reparent_success checks the chain against an expectation after a reparent. WARNING: an ambiguous bare name still resolves to the FIRST match and only lists the rest in ambiguous_matches (the other match is often a dated backup copy that backup_asset wrote under /Game/MCP_Backups), so run resolve_asset_by_name first or pass the full path.

Returns: { blueprint_name: string, blueprint_path: string, blueprint_valid: bool, parent_class: string, parent_class_path: string, has_parent: bool, parent_is_native: bool, blueprint_type: string, ambiguous_matches?: [string] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
blueprint_nameNoBlueprint asset short name (exact) or full package name. The full package name is tried first; the bare-name fallback scans /Game only, matching UBlueprint assets, and picks the first hit.
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.

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 cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds genuinely new behavior: it returns only ONE level, and an ambiguous bare name silently resolves to the FIRST match with the rest only listed in ambiguous_matches, often a dated backup under /Game/MCP_Backups. That is real operational context an agent needs.

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 and scoping are front-loaded, and the sibling routing plus ambiguity warning are placed before the return field listing. It is denser and longer than ideal, but every clause (sibling disambiguation, warning, return shape) carries information an agent needs.

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 no output schema, the description inlines the full return object, and it covers scope, resolution caveats, and when to prefer sibling tools. Nothing needed to call it correctly or interpret its result is missing.

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 description coverage is 100%, so the baseline is 3; the schema already documents blueprint_name resolution order and the blueprint_path alias. The description adds value on top by warning that bare-name resolution is first-match-only and can hit a backup copy, effectively guiding parameter usage.

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 and resource: reads which parent class a Blueprint asset inherits from, and enumerates exactly what is returned (parent name, path, native vs Blueprint, own type). It explicitly distinguishes itself from siblings by naming get_class_hierarchy, get_blueprint_children, and verify_reparent_success with their different scopes.

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 framing ('the first question to ask about an unfamiliar Blueprint') and names three alternatives with the conditions that select them (whole ancestor chain, descendants, post-reparent verification). It also supplies a prerequisite workflow: run resolve_asset_by_name or pass the full path before calling.

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