Skip to main content
Glama

save_game

Destructive

Writes a new default-valued SaveGame object to a specified slot, overwriting existing data. Returns success and message.

Instructions

Write a NEW default-valued SaveGame object of save_game_class (default UMCPSaveGame) to a slot with SaveGameToSlot, overwriting what the slot held; it does not save an object made by create_save_game. On desktop the file is Saved/SaveGames/.sav. Returns success and message.

Returns: { slot_name: string, user_index: int, success: bool, message: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slot_nameYesSave slot name where the game will be saved
user_indexNoPlatform user index for the save system; default 0 (the generic desktop save system ignores it)
save_game_classNoName of a loaded, concrete USaveGame subclass, e.g. "MySaveGame" (found with FindFirstObject, never loaded from disk); default UMCPSaveGame

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.0
    • changedInput schema / properties / save_game_class / description
      Previous value: -"Optional SaveGame subclass; defaults to the plugin's concrete UMCPSaveGame (the abstract USaveGame base is rejected)"New value: +"Name of a loaded, concrete USaveGame subclass, e.g. \"MySaveGame\" (found with FindFirstObject, never loaded from disk); default UMCPSaveGame"
    • changedInput schema / properties / user_index / description
      Previous value: -"Optional user index, default 0"New value: +"Platform user index for the save system; default 0 (the generic desktop save system ignores it)"
  2. First observedv1.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false. The description adds real value beyond them: it discloses that the slot is overwritten, that the object is newly constructed with default values rather than an existing one, and the on-disk path (Saved/SaveGames/<slot>.sav). It doesn't mention permissions or any return-on-failure behavior beyond the message field, keeping it a notch below full disclosure.

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 critical 'NEW default-valued object / overwrites the slot' distinction is front-loaded in the first clause. The Returns line is justified since there is no output schema, though the single dense run-on sentence carries more clauses than strictly needed.

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

Completeness4/5

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

For a 3-param mutation tool with no output schema, it covers the destructive overwrite semantics, the object-construction behavior, the on-disk location, and the return shape. Combined with annotations that already flag the write/destructive profile, little is missing apart from failure-mode detail.

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 slot_name, user_index, and save_game_class are already fully documented, including the UMCPSaveGame default and the 'ignored on desktop' note for user_index. The description only restates the class default, adding no semantics beyond the schema, matching the baseline for high coverage.

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/save) plus the exact resource (a NEW default-valued SaveGame object to a slot via SaveGameToSlot). It explicitly distinguishes itself from a sibling: 'it does not save an object made by create_save_game.' An agent can tell it apart from create_save_game/save_game_to_memory without opening either schema.

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?

Gives clear context (writes a fresh default object to a slot, overwriting the prior contents) and an explicit exclusion relative to create_save_game. However, it never names the alternative tool an agent should use to persist an object built by create_save_game, so the routing guidance stops short of being fully explicit.

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