Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

read_datatable_from_package_file

Read-onlyIdempotent

Read a DataTable from any .uasset file on disk, including backups, via a throwaway mount so live assets remain untouched; returns rows as JSON.

Instructions

Read a DataTable from any .uasset file on disk (e.g. a backup) under a throwaway mount, so a live asset with the same /Game name is untouched; then unmounts and, by default, garbage-collects. Returns table_name, row_struct, row_count and rows as native JSON, or one row via row_name.

Returns: { package_file, mount_root, package_name, table_name, row_struct, row_count, rows:[{row_name,row_data}] } (or, for a single row_name, { ..., row_name, row_json, row_data })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
row_nameNoOptional single row to return; when omitted every row is returned
file_pathNoAlias of package_file (OS path to the .uasset, e.g. "D:/Backup/DT_Items.uasset"); package_file wins when both are given
object_nameNoOptional name of the DataTable object inside the package (defaults to the first UDataTable / the package's primary asset)
package_fileNoAbsolute filesystem path to the external .uasset (alias: file_path)
collect_garbageNoWhen true (default) force a GC purge of the throwaway load after reading

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • addedInput schema / properties / file_path / description
      Added value: +"Alias of package_file (OS path to the .uasset, e.g. \"D:/Backup/DT_Items.uasset\"); package_file wins when both are given"
    • removedInput schema / required
      Removed value: -[
-  "package_file"
-]
  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?

Beyond the readOnly/idempotent/non-destructive annotations, it discloses real side-effect behavior: the file is mounted under a throwaway mount to protect the live asset, then unmounted and by default garbage-collected. That mount/GC lifecycle is exactly the kind of context the annotations cannot convey, and it is stated plainly.

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 key behavior (throwaway mount, unmount/GC) before the return shape, so an agent gets the gist immediately. The explicit 'Returns:' block is largely warranted given there is no output schema, though it slightly overlaps the earlier prose.

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 description carries the full burden of return shape and it delivers the exact field set for both the all-rows and single-row cases. Combined with the mount/GC behavior and 100% schema coverage, an agent has everything needed to call it correctly.

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 the schema already documents every parameter including the file_path/package_file alias and the collect_garbage default. The description only echoes row_name's single-row behavior and the default GC, adding little beyond the schema. Baseline 3 is appropriate.

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 (Read) plus resource (a DataTable) and crucially the scope: from any .uasset file on disk rather than the live asset. This distinguishes it from the many live-asset DataTable siblings (get_data_table_rows, get_data_table_row, export_data_table_as_json) that operate on mounted /Game content.

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?

The parenthetical '(e.g. a backup)' and the 'so a live asset with the same /Game name is untouched' clause communicate when this is the right tool: reading external/off-disk packages. It gives clear context but does not explicitly name the sibling to use instead for live assets, so it stops short of full when/when-not routing.

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