Skip to main content
Glama

set_bp_variable_default

DestructiveIdempotent

Set a Blueprint-declared variable's default value, writing the live CDO and serialized description so it survives save/reload. Inherited variables are refused.

Instructions

Set the default value of a variable DECLARED on this Blueprint: writes the live CDO and mirrors the result back into the serialized variable description so it survives save/reload. LIMIT (not a lie, a hard boundary): it CANNOT touch an INHERITED variable -- it answers "Variable 'X' is not declared on this blueprint" -- so the "child that only overrides a parent default" pattern needs the CDO route (execute_python + set_editor_property + compile_blueprint + save). And on a class with actors already placed in a level, the placed instances keep their serialized value: verify on the instances, never on the CDO.

Returns: { blueprint_name, variable_name, default_value, roundtrip_verified } -- default_value is re-exported from the CDO after the write, so it is the real stored value. WARNING: roundtrip_verified:false means the exported text does NOT re-import into the type (e.g. FGameplayTagContainer): the CDO holds the right value and the compiler's property copy carries it, but the serialized description was deliberately left empty because feeding an unparseable string back through a Full compile ZEROES the default. Verify that variable on the CDO after compiling, and prefer wiring it in the graph if it must survive a fresh regeneration.

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.
valueNoNew default in exported-text form, parsed into the variable's type; empty allowed. A value the type cannot parse is an error AND the previous value is restored (the engine's struct import zeroes the target before parsing, so a failed parse wipes the CDO).
variable_nameYesName of a variable declared on THIS Blueprint (inherited ones are refused)
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`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say it is destructive, non-read-only and idempotent; the description goes far beyond that with the PIE-refusal mechanics, the CDO-write mirroring that survives save/reload, the fact that already-placed instances keep their serialized value, and that a failed parse restores the prior value. This is exactly the operational context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and most sentences carry operational weight, but the prose is dense and editorializing ('not a lie, a hard boundary', long parenthetical tangents) that could be tightened. It is longer than needed even for a tool this hazardous.

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 (blueprint_name, variable_name, default_value, roundtrip_verified) and explains what roundtrip_verified:false actually means, plus verification guidance. Nothing an agent needs to invoke and interpret 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, but the description adds real meaning: it ties variable_name to the declared-only constraint and frames value as exported-text form feeding the struct import path, including the empty-allowed and parse-failure behavior. The added semantics slightly exceed what the schema states.

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 ('Set the default value of a variable DECLARED on this Blueprint') and immediately distinguishes scope by naming what it will not touch (inherited variables). An agent can separate this from sibling setters like set_pin_default_value or set_property_value 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?

Gives explicit when-not (inherited variables are refused with a specific error string), the named alternative route (execute_python + set_editor_property + compile_blueprint + save), and the PIE precondition with the force escape hatch. Nothing about routing or timing 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