Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

create_attribute_set_asset

Creates or reuses an AttributeSet Blueprint, adds gameplay attribute variables with defaults, and compiles/saves it for use in Unreal Engine GAS.

Instructions

Create (or reuse) an AttributeSet Blueprint at package_path/name like create_attribute_set_blueprint (a Blueprint of another class there is an error, and is left untouched), add one FGameplayAttributeData variable per attributes entry, then compile and save it. A name the class already has is skipped and listed in skipped_attribute_names; success is false when an added attribute is missing from the compiled class or did not get its default_value. Refused during PIE.

Returns: { name: string, asset_path: string, parent_class: string, generated_class: string, is_attribute_set: bool, already_existed: bool, attributes_added: int, added_attribute_names: [string], skipped_attribute_names: [string], failed_attribute_names: [string], attributes_applied: bool, created: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesAsset name without a path, e.g. "AS_Character".
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.
attributesNoArray of {"name": "Health", "default_value": 100} objects; default_value (default 0) becomes the BaseValue and CurrentValue of the compiled default. Entries without a name are ignored.
package_pathNoContent folder for the new asset, e.g. "/Game/GAS/Attributes"; defaults to /Game/Blueprints.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.2.0
    • changedInput schema / properties / attributes / description
      Previous value: -"Optional list of {name, default_value} attribute descriptors"New value: +"Array of {\"name\": \"Health\", \"default_value\": 100} objects; default_value (default 0) becomes the BaseValue and CurrentValue of the compiled default. Entries without a name are ignored."
    • changedInput schema / properties / name / description
      Previous value: -"Asset name, e.g. AS_Character"New value: +"Asset name without a path, e.g. \"AS_Character\"."
    • changedInput schema / properties / package_path / description
      Previous value: -"Target content path, defaults to /Game/Blueprints"New value: +"Content folder for the new asset, e.g. \"/Game/GAS/Attributes\"; defaults to /Game/Blueprints."
  2. 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 supply non-mutating safety hints, so the description carries the behavioral load and does so richly: what gets created vs reused, what happens to a conflicting class, how partial failure is reported via success=false and failed_attribute_names, and the PIE/CheckForWorldGCLeaks hazard behind force.

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 action, then failure semantics, then the PIE caveat, then the return shape. Dense and parenthetical-heavy but each clause carries information; it could be split but nothing 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 the embedded Returns object is essential and fully compensates, covering both success and failure fields. Combined with the conflict/PIE rules, an agent has everything needed to call and interpret this tool.

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 coverage is 100% and the schema descriptions are already detailed (name format, force/PIE rationale, attributes shape, package_path default). The description mostly restates the pipeline rather than adding parameter semantics beyond the schema, so the baseline 3 is warranted.

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 ('Create (or reuse) an AttributeSet Blueprint') and enumerates the exact pipeline steps (add FGameplayAttributeData variables, compile, save). It explicitly anchors itself against the sibling create_attribute_set_blueprint by describing how this differs in scope.

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 conditional guidance: reuse when the name already exists (skipped_attribute_names), error when a Blueprint of another class occupies the path, and refusal during PIE with force=true as the override. It does not fully spell out when to prefer this over create_attribute_set_blueprint, but the context is clear.

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