Skip to main content
Glama

rename_bp_variable

Destructive

Rename a Blueprint member variable in place, preserving its VarGuid, type, default value and flags while rewiring every Get/Set node in this and dependent Blueprints.

Instructions

Rename a member variable DECLARED on this Blueprint, KEEPING everything the delete+re-add workaround throws away: the VarGuid, the type, the default value, the category, the tooltip and the replication flags -- and, crucially, RE-WIRING every Get/Set node that reads it, in this Blueprint and in every dependent one. This is the only correct way to rename an authored variable in place (e.g. to translate its name). WARNING: it refuses a variable that has a RepNotify function: the engine's own rename opens a MODAL dialog for that case (FSuppressableWarningDialog, which does NOT honour unattended mode) and would hang the editor waiting for a click -- clear the RepNotify with set_bp_variable_replication, rename, then set it back. WARNING: dependent Blueprints are only repaired if they are LOADED: this command loads the ones the Asset Registry reports as referencers first, and reports them in referencers_loaded, but an asset that references it in a way the registry does not see keeps the old name silently. It does NOT create CoreRedirects, so a saved game, a DataTable cell or a Python set_editor_property that names the variable as text is NOT fixed -- grep for those. Run compile_blueprint afterwards and save_asset on this Blueprint AND on every referencer.

Returns: { blueprint_name, old_name, new_name, renamed (re-read: true only if new_name exists and old_name is gone), referencers_loaded: [string], repnotify_cleared: bool, warning? }

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.
new_nameYesNew name. Must be a legal identifier and free across the WHOLE class chain (the engine does not check this and would happily create a duplicate). Case-only changes are allowed.
old_nameYesCurrent name of a variable declared on THIS Blueprint; inherited/native ones are refused.
blueprint_nameNoBlueprint asset name or path owning the variable.
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
load_referencersNoOptional bool (default true). Load the Blueprints the Asset Registry lists as referencers BEFORE renaming, so the engine's reference fixup reaches them; it only ever sees what is already in memory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the annotations (which only declare destructive=true, idempotent=false). It discloses the RepNotify refusal and why (modal FSuppressableWarningDialog ignores unattended mode), the PIE refusal, silent un-repaired registries, missing CoreRedirects (saved games, DataTable cells, set_editor_property text refs), and the re-read semantics of `renamed`.

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 delete+re-add contrast are front-loaded, and nearly every sentence carries operational weight (specific failure modes, exact remediation commands). It is dense and long, but not padded — the density is justified for a destructive, easily-misused operation.

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 supplies the return shape (renamed re-read, referencers_loaded, repnotify_cleared, warning), the post-rename checklist, and the known silent-failure gaps. An agent has everything needed to call it correctly and verify the result.

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 force, load_referencers, blueprint_path alias, and the name constraints. The description adds little parameter-level meaning beyond what the schema already supplies, 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 and resource ('Rename a member variable DECLARED on this Blueprint') and immediately distinguishes this from the delete+re-add workaround it replaces. It is unambiguously separable from sibling tools like delete_bp_variable or add_blueprint_variable.

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 says when this is the right tool ('the only correct way to rename an authored variable in place'), names the alternative workflow it supersedes, and prescribes prerequisites/follow-ups: clear RepNotify with set_bp_variable_replication first, then compile_blueprint and save_asset on the Blueprint and every referencer. Nothing is left to inference.

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