Skip to main content
Glama

Copy the save aside

save_snapshot

Copy the current world and character files to a labeled backup before a mutating run, so the state can be restored later. Use it before commands that change game data; it refuses while the game is running to avoid copying mid-write files.

Instructions

Copy this world and its characters aside, so a run can be undone.

WHAT THIS IS FOR. The mutating verbs write to a real install and none of that FAILS — it accumulates. Enemy NPCs do not survive a reload, so spawn looks harmless, but give writes the character file, time and weather live in the world, and settile changes it for good. The damage is invisible when it is done and shows up later as a measurement nobody doubts.

Take one before a run that mutates, and save_restore after it.

REFUSES WHILE THE GAME IS RUNNING, naming the pids. A running tModLoader owns these files and writes them out on its own schedule, so a copy taken now is mid-write. Stop the session first.

Copies the configured world's .wld and .twld and every .plr/.tplr — not the whole Worlds directory, which measured 41MB against 3MB for one world, and not .bak files, which are the game's own safety net.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeYes
filesYes
labelYes
takenYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.3

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behavioral traits: it refuses while the game is running, names the copied file types (.wld, .twld, .plr/.tplr), and explicitly excludes the whole Worlds directory and .bak files. This gives the agent a precise model of what the tool will and will not do.

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?

The description is longer than strictly necessary, but it is well-structured with bolded section headers and front-loaded purpose. The detailed rationale about mutating verbs, file sizes, and the running-game refusal earns its place because it directly affects when and how the tool should be invoked.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers when to use the tool, what files are copied, and the running-game refusal, and an output schema exists so return values do not need explanation. However, the required label parameter is left undefined, which is a meaningful gap for an agent trying to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one required parameter, label, with 0% schema description coverage, and the description never explains what label means, what format it should take, or how it is used to identify the snapshot for later restoration. The 'before a run' phrasing only weakly implies the label may identify the run, which is not enough to compensate for the missing documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: it copies the configured world and its characters aside so a run can be undone. It also names save_restore as the companion for after the run, but it does not explicitly distinguish this tool from the sibling save_snapshots, so it lacks full sibling differentiation.

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 description explicitly says to take a snapshot before a mutating run and use save_restore after it, and it warns that the tool refuses while the game is running and tells the agent to stop the session first. This gives clear context and an exclusion, though it does not discuss alternative tools such as save_snapshots for listing existing snapshots.

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