Skip to main content
Glama

add_data_table_row

Destructive

Create or overwrite a DataTable row using JSON column values; invalid imports fail the whole write, and unrecognized columns are reported.

Instructions

Create a new row in a DataTable (upsert -- it overwrites if the key exists), passing columns as a plain JSON object. Values go through reflection, so scalars, enums by name, nested structs and arrays all work. It fails the WHOLE write when any column cannot be imported, rather than committing a half-filled row with silent defaults, and lists anything it did not recognise in unknown_columns -- read that array, a typo'd column name is dropped, not an error. GameplayTag and GameplayTagContainer columns are the ones that reject a bare string: pass them in ExportText form, e.g. (TagName="A.B"). Use set_data_table_row to require the row to exist, or set_data_table_row_fields for a partial per-column update with before/after evidence.

Returns: success or error payload

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
row_dataYesObject of {column_name: value}; values may be string/number/bool
row_nameYesName (key) of the row to write
table_pathYesFull asset path of the DataTable (e.g. /Game/MyGame/DT_Example)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: all-or-nothing write semantics (fails the whole write rather than committing defaults), silent dropping of unrecognized columns into unknown_columns, and reflection-based value import. Annotations cover the safety profile (destructiveHint=true, readOnlyHint=false), so those need no restating. The only blemish is that describing itself as an upsert that overwrites sits in mild tension with idempotentHint=false, though this is not a hard contradiction.

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 its upsert caveat, then the failure/typo semantics, then sibling routing. Dense and mostly waste-free, but the trailing 'Returns: success or error payload' is near-zero information given there is no output schema to define the shape.

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 three-parameter mutation tool whose annotations already declare the safety profile and with no output schema to explain, the description covers the operational essentials: overwrite behavior, atomic failure, unknown_columns handling, and the special-case value encoding. Nothing an agent needs to call it correctly is missing.

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 goes beyond the schema by explaining that row_data values pass through reflection so nested structs and arrays work (the schema only advertises string/number/bool) and that GameplayTag columns need ExportText form like (TagName="A.B"). table_path and row_name get nothing beyond the schema, keeping this out of the top band.

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 a new row in a DataTable') and immediately qualifies the real semantics as an upsert that overwrites on key collision. It names the two sibling alternatives by name, so an agent can distinguish it from set_data_table_row and set_data_table_row_fields 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 Guidelines5/5

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

Explicitly gives the when-to-use-this-versus-what conditions: set_data_table_row when the row must already exist, set_data_table_row_fields for a partial per-column update with before/after evidence. This is exactly the routing guidance the tool selector needs.

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