Skip to main content
Glama

get_asset_last_modified

Read-onlyIdempotent

Read a .uasset file's last-modified timestamp and age to verify whether an asset was actually written to disk, catching save operations that reported success falsely.

Instructions

Read the .uasset file's last-modified timestamp (formatted string + Unix epoch) and how old it is in days and hours -- "was this asset actually written to disk when I saved it?", the disk-side oracle for a save whose return value claimed success. WARNING: It is a FILE timestamp: an asset edited in memory but not saved reports its old date, and Unreal does not distinguish creation from modification (the tool reads the same stamp for both). Use list_assets_modified_since to sweep a whole folder by date, and list_dirty_packages for unsaved-in-memory changes. Resolution matches get_asset_by_name (full package name first, then a /Game-only exact-name scan, first hit wins with the rest in ambiguous_matches).

Returns: { asset_name: string, asset_path: string, file_path: string, last_modified: string, last_modified_timestamp: int, file_exists: bool, asset_class: string, age_days: number, age_hours: number, ambiguous_matches?: [string] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asset_nameYesEXACT asset name, or a full package name (which is tried first and is the only form that reaches outside /Game)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: the WARNING that an in-memory edit reports its old date, that Unreal does not distinguish creation from modification, and the resolution/ambiguity behavior. This is exactly the disk-vs-memory nuance an agent cannot infer otherwise.

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?

Purpose, warning, alternatives, and return shape are front-loaded and dense with useful content. The prose is somewhat run-on with embedded quotes and dashes, but nearly every clause earns its place, including the returns enumeration that substitutes for a missing output schema.

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?

With no output schema, the description enumerates the full return object, and annotations carry the safety profile. Combined with the resolution semantics and disk-vs-memory caveat, 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.

Parameters5/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 real meaning: full package name is tried first, then a /Game-only exact-name scan, first hit wins with the rest surfaced in ambiguous_matches. That resolution order is not derivable from the schema alone.

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 precise verb+resource: it reads the .uasset file's last-modified timestamp (formatted string + Unix epoch) plus age in days/hours. It explicitly distinguishes itself from list_assets_modified_since and list_dirty_packages, so an agent can route correctly without opening a 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?

Frames the tool as the 'disk-side oracle for a save whose return value claimed success' and names the exact alternatives for adjacent cases: list_assets_modified_since for folder-wide date sweeps and list_dirty_packages for unsaved in-memory changes. Both when-to-use and when-not are covered.

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