Skip to main content
Glama

save_asset

Destructive

Writes one Unreal asset package to disk by path and verifies the file persisted, so in-memory edits are kept and failed saves are caught.

Instructions

Write one asset's package to disk by its path and verify the result: still_dirty_after_save false and file_on_disk true are the proof, not saved.

Use it after an edit you want to keep, because most edit tools change the asset in memory only. save_level writes a level's .umap, and reload_asset_package throws an unsaved edit away instead. It writes exactly one package: a compile can dirty others, so run list_dirty_packages before a bulk save and read git status after.

path takes the path or the package that find_assets_by_name returns, as in {"path": "/Game/Core/BP_Door"}. readonly_roots chooses which folders count as vendored, and refuse_readonly whether a save under them is refused or only reported; leave both out to use the project's Read Only Content Roots, which refuse.

Refused during Play-in-Editor, where the engine would drop the write and still report success (see force). When a save fails otherwise, file_read_only says whether the file is read-only on disk (usually a Git LFS lockable file nobody has locked), and the error says whether that is the cause.

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, verification: object, verification_checks: [object], error?: string }

Input 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?

Beyond the annotations, it explains verification signals (still_dirty_after_save false and file_on_disk true, not merely saved), the single-package write behavior, the Play-in-Editor refusal risk, readonly-root enforcement, and failure diagnostics like file_read_only. These are meaningful behavioral details not supplied by the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and verification proof, then proceeds through usage, parameters, failure behavior, and return shape. Despite its length, it is structured and each section contributes necessary context for a destructive save tool with several edge cases.

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?

Given the lack of an output schema and the tool's complexity, the description includes the return object fields, verification checks, PIE refusal behavior, readonly-root handling, and failure diagnostics. An agent has enough context to invoke it correctly and interpret the result.

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 adds useful workflow context not in the schema: path may come from find_assets_by_name's path or package, and readonly_roots/refuse_readonly can be omitted to use the project's Read Only Content Roots. It largely reinforces the schema rather than replacing missing information, so it stops short of a 5.

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 states a specific verb and resource: write one asset's package to disk and verify the result. It distinguishes this from siblings by naming save_level and reload_asset_package and clarifying that it saves exactly one package rather than a level or an in-memory edit.

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?

It gives explicit when-to-use guidance: after an edit you want to keep, because most edit tools change the asset only in memory. It also names alternatives (save_level, reload_asset_package) and operational warnings, such as running list_dirty_packages before a bulk save and checking git status afterward.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.