Skip to main content
Glama

get_blueprint_variable_detailed_info

Read-onlyIdempotent

Read a Blueprint variable's full details—default value, structured type, and all property flags (replication, save game)—to verify persistence and replication without running the game.

Instructions

Read ONE variable's full detail: its default value, the structured type (category, sub-category object and container kind -- not just the pin category get_blueprint_variables gives you), and every checkbox of the variable Details panel -- is_instance_editable / is_expose_on_spawn / is_blueprint_read_only / is_expose_to_cinematics / is_replicated / replication_condition / save_game. This is the headless oracle for "does this variable really persist into a .sav?", which otherwise costs a co-op PIE session plus a binary grep of the slot file. save_game is reported from BOTH places the flag lives, because they disagree until you compile: save_game is CPF_SaveGame as AUTHORED (FBPVariableDescription::PropertyFlags, exactly what the editor checkbox writes) while save_game_generated is the same flag on the FProperty of the GENERATED class, which is the one the save archive consults -- so save_game:true + save_game_generated:false means MARKED BUT NOT COMPILED, and nothing will persist yet; save_game_matches says it in one field. Read is_replicated FIRST: replication_condition is always populated (COND_None by default) and only means anything when replication is on. default_value is read from the CDO when the class is compiled (default_value_source:"cdo"), so it does not come back EMPTY for arrays, maps and every variable of an already-compiled Blueprint. Booleans of this family are contrasted, not believed -- audit_replication is the ground truth for replication.

Returns: { blueprint_name: string, variable_name: string, default_value: string, default_value_source: "cdo"|"blueprint_description", default_value_serialized: string, var_type: string, property_type: string, var_type_detail: {category, sub_category, sub_category_object, sub_category_object_path, container}, is_instance_editable: bool, is_expose_on_spawn: bool, is_blueprint_read_only: bool, is_expose_to_cinematics: bool, is_replicated: bool, replication_condition: string, save_game: bool, save_game_generated: bool, save_game_generated_found: bool, save_game_matches: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
variable_nameYesName of a variable DECLARED on this Blueprint (e.g. "MyFloat"); inherited variables are not covered
blueprint_nameNoName of the blueprint
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.4/5.0
Behavior5/5

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

Annotations only establish that this is a safe read; the description carries substantial extra behavioral disclosure beyond that: default_value is read from the CDO so it won't be empty for arrays/maps, save_game is reported from both authored and generated sources with the disagreement semantics spelled out, and inherited variables are out of scope. This is exactly the kind of 'why the fields disagree' context annotations cannot supply.

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 dense save_game/replication caveats genuinely earn their place given there is no output schema. The prose is long and run-on with heavy backtick usage, but little of it is 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, so enumerating the returned fields (including the three save_game variants) is necessary and present. The subtle dual-source flag semantics and the replication_condition caveat are fully covered, so an agent has everything needed to interpret results correctly.

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?

With 100% schema description coverage the schema already documents all three parameters, and the description adds no syntax, format, or edge-case detail about them. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

Opens with a specific verb+resource+scope: 'Read ONE variable's full detail'. It explicitly contrasts itself with the sibling get_blueprint_variables ('not just the pin category get_blueprint_variables gives you'), so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for use (the headless oracle for save-persistence questions) and names alternatives with their roles ('audit_replication is the ground truth for replication'). It also prescribes read order ('Read is_replicated FIRST'). It falls short of explicit when-not-to-use conditions, but the routing guidance is strong.

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