Skip to main content
Glama

save_asset

Destructive

Write one Unreal .uasset package to disk and verify it persisted using still_dirty_after_save:false and file_on_disk:true, not just a success flag.

Instructions

Write ONE .uasset to disk by package path (a Blueprint, DataTable, material...) and VERIFY the effect: still_dirty_after_save:false plus file_on_disk:true is the oracle, not saved. Use save_level for the .umap and reload_asset_package to undo an in-memory edit instead. PIE: this is REFUSED while Play-in-Editor runs (it never stops or touches your session) -- the engine guard Editor.AllowSavingAssetsDuringPIE=0 rejects the write before attempting anything, so a save during play would report success without writing a byte. Stop PIE and retry, or pass force=true. WARNING: when it answers success:false with PIE down, a common cause is the file being READ-ONLY on disk (e.g. a Git LFS lockable file that has not been git lfs locked). You do not have to check that by hand: file_read_only is measured on every call and the error message states whether a read-only file IS or is NOT the explanation. WARNING: it writes exactly one package, so it cannot stop a compile cascade from dirtying a vendored asset that a LATER bulk save then rewrites -- list_dirty_packages before, git status after.

Returns: { path: string, package_name: string, saved: bool, success: bool, under_readonly_root: bool, readonly_root_matched: string, refused_readonly: bool, readonly_roots: [string], readonly_roots_defaulted: bool, still_dirty_after_save: bool, file_on_disk: bool, file_read_only: bool (measured on disk -- true means the file is read-only, e.g. an unlocked Git LFS lockable file), verification: object, verification_checks: [object], error?: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoFull asset path to save, e.g. /Game/MyGame/Core/BP_MyActor (an .Object suffix is tolerated). Must already exist or the call errors.
forceNoOptional. This command is REFUSED while a Play-in-Editor session is running: it either compiles a Blueprint (the reinstancer can retain a world, and CheckForWorldGCLeaks is Fatal -- it KILLS the editor) or writes to disk (Editor.AllowSavingAssetsDuringPIE=0 makes the engine refuse the write, so it would report success without writing a byte). Stop PIE and retry instead; force=true runs it anyway, at your own risk.
asset_pathNoAlias of `path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `path`.
readonly_rootsNoOptional array of long-path prefixes treated as vendored/upstream (default: the project's Read Only Content Roots). A save under one of them is REFUSED by default; see refuse_readonly. Pass [] to disable the classification entirely.
refuse_readonlyNoOptional bool. When true, a save whose package falls under one of readonly_roots is REFUSED (success:false, saved:false, refused_readonly:true) instead of performed. Default = the process-wide switch (mcp_common::IsReadOnlyRootSaveEnforcementEnabled(), true unless `mcp.ReadOnlyRootEnforcement 0`); when false the write happens and is only reported + ledgered.

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 only declare not-read-only/not-idempotent/destructive. The description goes far beyond: it defines the success oracle (still_dirty_after_save:false plus file_on_disk:true, not `saved`), documents the PIE refusal and the Editor.AllowSavingAssetsDuringPIE=0 guard, the silent-success failure mode, the read-only file diagnosis path, and the compile-cascade limitation. This is exactly the extra context the annotations cannot carry.

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: verb, scope, and oracle come first, then alternatives, then the PIE warning, then the read-only warning. Dense but every sentence earns its place. Slightly long, with warnings repeating PIE/read-only material already covered in the schema, but no filler.

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?

A 5-param destructive write tool with no output schema; the description supplies the return-shape oracle, the refusal condition, the silent-failure mode, the read-only diagnosis, and the bulk-save caveat. Nothing an agent needs to call or interpret this correctly is missing.

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% (baseline 3), and the description still adds meaning: path is 'must already exist or the call errors', force is framed as an at-your-own-risk PIE override rather than a generic flag, and the read-only-root behavior ties to the returned file_read_only field. The 'write exactly one package' constraint also disambiguates path semantics.

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 (Write ONE .uasset to disk), the exact unit of work (one package), and explicitly distinguishes itself from save_level (.umap) and reload_asset_package (undo in-memory edit). An agent can route without opening the 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?

Names three alternatives with selection predicates: save_level for the .umap, reload_asset_package to undo an in-memory edit, and the PIE case (refused during Play-in-Editor) with the mitigation (stop PIE or pass force=true). Also advises list_dirty_packages/git status around the call. Explicit when-to-use and when-not.

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