Skip to main content
Glama

set_data_asset_property

DestructiveIdempotent

Set a single reflected property on an Unreal DataAsset using UE text-form values, then verify it by reading back and returning old and new values.

Instructions

Write ONE reflected property on a DataAsset from a text value and verify it by reading back, returning old_value and new_value so the reply proves the change instead of merely claiming it. Values use UE text form: structs as "(X=1,Y=2,Z=3)", object references as a full asset path, GameplayTags as (TagName="A.B"). One property per call, so loop for several; get_data_asset_info dumps them all.

Returns: { data_asset_path: string, property_name: string, property_type: string, old_value: string, new_value: string, applied: bool, saved: bool }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueNoNew value as a string (numbers/bools accepted); structs use UE text form e.g. "(X=1,Y=2,Z=3)"; object refs use a full asset path.
property_nameYesName of the UPROPERTY to set (class property name).
data_asset_pathYesFull asset path of the DataAsset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real value beyond them: it states the write is verified by read-back and returns old_value/new_value, and the returned 'saved' flag hints at persistence. It still does not spell out what destruction means or whether the asset is persisted to disk.

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 and kept to three tight sentences with no filler. The dense parenthetical of value formats is justified because it is the main failure mode for this tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description enumerates the return object (paths, property_type, old/new value, applied, saved), which is exactly what an agent needs. Minor gap: the semantics of applied=false / saved=false and save prerequisites are not explained.

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 meaning beyond the schema: the GameplayTags text form (TagName="A.B") is not in the schema, and it reinforces the one-property-per-call constraint that shapes how 'value' should be used.

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 ('Write ONE reflected property on a DataAsset from a text value') and explicitly bounds scope to one property per call. It also distinguishes itself from the read-side sibling by pointing to get_data_asset_info.

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 invocation context: one property per call, loop for several, and get_data_asset_info dumps them all. It names the alternative for the bulk-read case, though it offers no explicit when-not-use or prerequisite conditions (e.g. save requirements).

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