Skip to main content
Glama

add_struct_member

Add a field to a Blueprint struct programmatically, growing data shapes like DataTable rows or save records. Rolls back on name collisions and returns an error, never leaving orphaned members.

Instructions

Add a field to a Blueprint (user-defined) struct: the way to grow a data shape -- a DataTable row struct, a save record, a component's payload -- without opening the struct editor. Honest on collisions: if the new name is invalid or already used it ROLLS BACK the auto-named member it had to create first and returns an error, instead of reporting success under the engine's MemberVar_N name and leaving orphans behind. Adding a field to a struct a DataTable already uses changes every row (new field at its default), so re-read the table afterwards. get_struct_members lists what is there; rename_struct_member and remove_struct_member are the edits.

Returns: { struct_path, member_name, member_type, member_count }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
member_nameYesNew member name.
member_typeYesType string resolved through the Blueprint pin-type resolver: scalars (bool, int, int64, float, string, name, text, byte), plus struct/enum/class/object types addressed by name or asset path. An unresolvable string is an error, not a silent default.
struct_pathYesFull asset path of the struct (e.g. /Game/Blueprints/MyStruct).

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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by disclosing the collision path: an invalid or duplicate name rolls back the auto-named member rather than silently succeeding as MemberVar_N. It also warns that adding a field to a struct a DataTable uses changes every row, and reveals the return payload, all of which an agent needs to avoid silent corruption.

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 purpose in the first clause, then the collision semantics, then the side effect, then the sibling routing. It is dense but slightly padded with rhetorical flourishes ('Honest on collisions', 'the way to grow a data shape') that could be trimmed without losing information.

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?

For a mutating struct editor with no output schema, the description supplies the missing pieces: rollback/error semantics on name collision, the mutation's blast radius on DataTable-consuming structs, the sibling tools for other operations, and the return shape. Nothing an agent needs to call this safely is absent.

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 member_name, member_type (including the pin-type resolver and unresolvable-string error) and struct_path are already fully documented in the schema. The description adds no additional per-parameter syntax or format detail, so the 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 and resource ('Add a field to a Blueprint (user-defined) struct') and clarifies the scope: it edits the struct data shape rather than opening the struct editor. It also names the sibling tools it is not (get_struct_members, rename_struct_member, remove_struct_member), so an agent can distinguish it from the surrounding struct tools without opening any 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 concrete usage context ('the way to grow a data shape -- a DataTable row struct, a save record, a component's payload') and routes the agent to alternatives: get_struct_members for reading, rename/remove_struct_member for the other edits. It stops short of an explicit when-not-to-use rule or a stated precondition (e.g., struct must exist), so it is strong but not fully prescriptive.

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