Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

set_data_table_cell

DestructiveIdempotent

Set a specific element in a DataTable array column by row index, editing a struct sub-field or scalar value via ImportText, then save it. Use for targeted array cell updates without JSON/CSV imports.

Instructions

Set one element of an array column in a DataTable row (a field of a struct element, or a scalar element) by direct ImportText, bypassing the JSON/CSV importer, and save. Returns before_value, after_value, write_verified; an unregistered GameplayTag still becomes None (write_verified:false) and is saved anyway.

Returns: { table_path, row_name, column_name, row_index, cell_property, resolved_property, array_length, before_value, after_value, changed, already_set, import_succeeded, write_verified, success, warning?, saved, save_error? }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesExportText/ImportText string to write (e.g. "Material.Bone" for a bare FGameplayTag value, or an enum's internal OR display name)
row_nameYesName (key) of the row to edit
row_indexYesIndex into that array to edit (0-based; errors honestly if out of range, never a silent OOB read/write)
data_tableNoAlias of table_path (the DataTable asset path, e.g. "/Game/Data/DT_Items"); table_path wins when both are given
table_pathNoFull asset path of the DataTable (data_table also accepted)
column_nameYesName of the row-struct field holding the array (display name or authored/internal name both accepted, same fallback as get_data_table_column)
cell_propertyNoName of the sub-field on the array element STRUCT to set (display or authored name); omit/empty for a scalar array (e.g. TArray<FGameplayTag>/TArray<FName>) to edit the element itself

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • addedInput schema / properties / data_table / description
      Added value: +"Alias of table_path (the DataTable asset path, e.g. \"/Game/Data/DT_Items\"); table_path wins when both are given"
    • changedInput schema / required
      Previous value: -[
-  "table_path",
-  "row_name",
-  "column_name",
-  "row_index",
-  "value"
-]New value: +[
+  "row_name",
+  "column_name",
+  "row_index",
+  "value"
+]
  2. First observedv1.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=true, idempotent=true), the description discloses the write mechanism (direct ImportText, no importer), that the asset is persisted ('and save'), and a non-obvious failure mode: an unregistered GameplayTag silently becomes None with write_verified:false yet is still saved. That last point is exactly the kind of hidden consequence an agent needs.

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?

The purpose and mechanism are front-loaded in the first sentence, and the returns block is useful given there is no output schema. Minor redundancy: before_value, after_value, and write_verified appear both in prose and in the Returns list.

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?

With no output schema, the description compensates by enumerating the return shape, and it covers the mutation/save behavior and a key failure mode for a 7-parameter tool. It stops short of mentioning prerequisites such as source-control checkout or asset-lock expectations, so it is strong but not exhaustive.

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 every parameter (value format, row_index 0-based behavior, cell_property scalar-vs-struct semantics, table_path/data_table alias) is already fully documented in the schema. The description restates the ImportText value format but adds little beyond it, 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?

The description opens with a precise verb+resource+granularity: 'Set one element of an array column in a DataTable row', clarifying it edits a single array element (struct field or scalar) rather than a whole row. This distinguishes it from the many sibling row-level setters (set_data_table_row, set_data_table_row_fields) without the agent needing to open 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 Guidelines3/5

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

'bypassing the JSON/CSV importer' implicitly differentiates it from the *_from_json siblings, and the element-level scope implies when to pick it over a row-level setter. However, no alternative tool is named and there is no explicit when-not guidance or stated prerequisite, so usage is only implied.

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