Skip to main content
Glama

verify_reparent_success

Destructive

Verify a Blueprint reparent succeeded by checking the expected parent class, compile status, and any lost components or variables against counts captured beforehand.

Instructions

Check, after a reparent_blueprint, that the Blueprint really ended up where you wanted: it confirms the parent class against an expectation, reports the compile status, and -- when you feed it counts captured BEFOREHAND -- verifies no components or variables were lost, listing every failed invariant in regressions[]. This is the oracle for a reparent, because reparent_blueprint's own return value says nothing about whether the class survived it. WARNING: read-only by default, which means it reports the CACHED Blueprint->Status: pass force_compile=true to recompile and get the real status plus the compiler messages (compile_messages[] is empty without it, and compile_ran tells you which mode you got). Component count comes from the compiled CDO (native + SCS + inherited). Omit the expected_* counts to skip those invariants; get_blueprint_scs_tree or get_blueprint_variables_list before the reparent is where they come from.

Returns: { blueprint_name, blueprint_path, parent_class, expected_parent_class, parent_match, compile_status, compile_match, compile_ran, compile_messages:[{severity,message}], compile_num_errors, compile_num_warnings, component_count, expected_component_count, components_match, variable_count, expected_variable_count, variables_match, regressions:[string], success }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoOptional. This command is REFUSED while a Play-in-Editor session is running: it either compiles a Blueprint (the reinstancer can retain a world, and CheckForWorldGCLeaks is Fatal -- it KILLS the editor) or writes to disk (Editor.AllowSavingAssetsDuringPIE=0 makes the engine refuse the write, so it would report success without writing a byte). Stop PIE and retry instead; force=true runs it anyway, at your own risk.
force_compileNoOptional (default false): recompile to obtain the real compile status AND the compiler messages (compile_messages[] is empty without it -- compile_ran says which).
blueprint_nameNoBlueprint asset name or path.
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
expected_parent_classYesClass name or path the Blueprint should now inherit from.
expected_variable_countNoOptional: own-variable (NewVariables) count captured before the reparent.
expected_component_countNoOptional: CDO component count captured before the reparent.

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?

Goes well beyond the annotations: it discloses the cached-vs-recompiled status distinction (compile_ran, empty compile_messages[] without force_compile), where component count is measured from (compiled CDO: native + SCS + inherited), that failures are enumerated in regressions[], and the PIE-refusal semantics that make force risky. The default read-only mode versus the compiling/writing mode is clearly delineated.

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 the core purpose and the branch that matters (force_compile), and dense with useful detail. It is long and repeats some ground already covered in the schema's parameter descriptions (the force_compile / compile_messages explanation) and re-lists the full return shape, which costs some efficiency.

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 7-parameter verification tool with no output schema, the description carries the full burden and does: it inlines the return shape, explains each invariant's source, and covers the risky compile mode. An agent can call this correctly and interpret the result without further context.

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 real meaning: it explains the provenance of expected_component_count / expected_variable_count and what happens when they are omitted, and clarifies expected_parent_class as the comparison oracle. It does not add syntax details, but the added semantic framing exceeds the schema alone.

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 precise verb+resource+scope: post-reparent verification that confirms parent class against an expectation, reports compile status, and checks for lost components/variables. It explicitly distinguishes itself from reparent_blueprint ("its own return value says nothing about whether the class survived it") and names the sibling tools that supply the expected counts.

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?

Says exactly when to call it ("after a reparent_blueprint"), what to feed it ("counts captured BEFOREHAND"), and how to obtain those counts (get_blueprint_scs_tree / get_blueprint_variables_list). It also states when invariants are skipped ("Omit the expected_* counts to skip those invariants") and which mode to pick (force_compile).

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