Skip to main content
Glama

reconcile_function_signature

Destructive

Sync a local function graph's parameter pins with its parent UFUNCTION after a reparent. Adds missing pins by default or reports and removes extras, without rebuilding downstream nodes.

Instructions

Repair a LOCAL function graph's parameter pins so they match a parent UFUNCTION -- for an override whose signature went stale after a reparent -- WITHOUT nuking the graph's downstream nodes, which is what re-creating the override by hand costs you. It diffs the parent's parameters against the function's entry/result pins: mode='add_missing' (the default) only ADDS the missing pins, so it is non-destructive and safe to run blind; mode='remove_extra' / 'mirror' also DROP pins the parent lacks, which can sever downstream connections, and are therefore gated behind force_remove=true -- without it the extra pins are merely REPORTED (partially_implemented=true).

Returns: { blueprint_name, function_name, parent_class, mode, added:[{name,direction}], removed:[{name,direction}], extra_pins:[{name,direction}], missing_pins:[{name,direction}], removal_performed, partially_implemented, note, success }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoOptional (default 'add_missing'): 'add_missing' | 'remove_extra' | 'mirror'.
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_removeNoOptional (default false): actually remove extra pins for 'remove_extra'/'mirror' (may drop connections).
parent_classNoOptional: class whose UFUNCTION defines the target signature (default: the Blueprint's current ParentClass).
function_nameYesName of the local function graph to reconcile.
blueprint_nameNoBlueprint asset name or path owning the function.
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 flag destructiveHint=true, but the description goes far beyond: it explains mode-conditional destructiveness (which modes drop pins and sever downstream connections), the force_remove gate, the partially_implemented reporting behavior, and the PIE refusal with its engine-level rationale (CheckForWorldGCLeaks Fatal, Editor.AllowSavingAssetsDuringPIE=0 causing silent no-write). This is unusually rich behavioral context that the annotations alone could not convey.

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 the safe default are front-loaded, and every clause earns its place by carrying a distinct constraint. The em-dash asides and the parenthetical engine-internals explanation are dense and slightly winding, but they are informative rather than filler.

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, yet the description enumerates the full return object (added/removed/extra_pins/missing_pins, removal_performed, partially_implemented, success), so an agent knows what it gets back. Combined with mode semantics, gating, and the PIE precondition, nothing needed to invoke this correctly 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 coverage is 100%, so the baseline is 3. The description adds real meaning on top: it supplies the default for mode ('add_missing'), defines what force_remove actually does (hard-removes pins and may drop connections), and explains the force PIE override, plus clarifies blueprint_path is an alias of blueprint_name. It stops short of treating each of the 7 params, which keeps it at 4.

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: repairing a local function graph's parameter pins to match a parent UFUNCTION. It names the exact scenario (override whose signature went stale after reparent) and explicitly distinguishes itself from the alternative of re-creating the override by hand, so an agent can tell it apart from reparent_blueprint/verify_reparent_success siblings.

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 (stale override signature), which mode to choose and why ('add_missing' is non-destructive and safe to run blind), when the destructive modes apply and their gating (force_remove=true), plus when NOT to run (during PIE). Conditions and consequences are spelled out rather than 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