Skip to main content
Glama

get_blueprint_variables_list

Read-onlyIdempotent

List a Blueprint's own variables with names, categories, tooltip, and replication/UI flags to check what state it owns and whether it replicates.

Instructions

List the variables a Blueprint AUTHORED itself (UBlueprint::NewVariables) with name, pin category, category, tooltip and the flags that matter for co-op and UI work: is_public (BlueprintVisible), is_editable, is_blueprint_read_only, is_replicated (CPF_Net) and is_expose_on_spawn. The quick "what state does this Blueprint own, and is it replicated?" listing. WARNING: own variables only: inherited variables, native C++ UPROPERTYs and component-backed variables are NOT here -- use get_class_properties on the generated class (..._C) for the full property surface, or get_blueprint_variable_detailed_info for one variable's full descriptor and default value.

Returns: { blueprint_name: string, blueprint_path: string, variables: [object], variables_count: int, max_results: int, results_truncated: bool, blueprint_valid: bool, ambiguous_matches?: [string] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
max_resultsNoMaximum variables to return, 1..10000 (default 1000)
blueprint_nameNoBlueprint asset short name (exact) or full package name; an ambiguous bare name resolves to the first hit and lists the rest in `ambiguous_matches`
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.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds the critical behavioral constraint beyond that: own variables only, with inherited variables, native C++ UPROPERTYs and component-backed variables explicitly excluded, plus a note on how ambiguous bare names resolve.

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 scope statement and a memorable one-line summary before the WARNING and alternatives. The enumerated flag list is dense but each item (is_public, is_replicated, etc.) carries real meaning; slightly long but no filler sentences.

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, but the description itself enumerates the return shape (blueprint_name, blueprint_path, variables, variables_count, results_truncated, ambiguous_matches). Combined with the scope caveat and alternatives, an agent has everything needed to call and interpret it 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?

Schema description coverage is 100%, so the schema already documents max_results, blueprint_name and the blueprint_path alias. The description adds nothing about parameter syntax or values beyond structured fields; baseline 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+resource and nails scope: variables a Blueprint 'AUTHORED itself (UBlueprint::NewVariables)', with the exact fields returned. It is clearly distinguishable from siblings like get_blueprint_variables (full surface) and get_blueprint_variable_detailed_info (single 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 frames the use case ('the quick what state does this Blueprint own, and is it replicated? listing') and gives a WARNING with concrete alternatives: get_class_properties on the ..._C generated class for the full property surface, and get_blueprint_variable_detailed_info for one variable's full descriptor.

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