dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Restore a backup

dos2_restore

Destructive

Restore a Divinity: Original Sin 2 campaign from a backup, undoing an earlier write by returning saved files and removing files it created; current files are backed up first.

Instructions

Undoes an earlier write: puts back the files saved in the given backup and deletes the files that the backed-up operation had created. Restoring a "full" backup brings back every file of the campaign.

The current state of the affected files is itself backed up first under the label "before-restore", so a
restore can be undone too. Fails with an error while the game process is running unless allow_running=true. Fails with an error when the backup id does not exist. Returns the id of
the before-restore backup and restored_from.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "campaign": "<campaign>",
      "backup": "<backup>"
    },
    "name": "dos2_restore"
  }
}

Input Schema

Name	Required	Description
`backup`	Yes	Backup id exactly as listed by dos2_backups.
`campaign`	Yes	The campaign to work on: its name, its folder name, its UUID, or a unique part of any of them. dos2_status lists the campaigns.
`allow_running`	No	Keep false. Set true only after the user has confirmed that the running game sits in the main menu: a write into a campaign that is loaded in the game gets lost or damages it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.1Nov 11, 2026

addedInput schema / properties / allow_running / description

Added value: +"Keep false. Set true only after the user has confirmed that the running game sits in the main menu: a write into a campaign that is loaded in the game gets lost or damages it."

addedInput schema / properties / backup / description

Added value: +"Backup id exactly as listed by dos2_backups."

addedInput schema / properties / campaign / description

Added value: +"The campaign to work on: its name, its folder name, its UUID, or a unique part of any of them. dos2_status lists the campaigns."

First observedv0.1.0Nov 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true/readOnly=false/idempotent=false, and the description goes well beyond them: it discloses that current state is snapshotted first under 'before-restore' so the operation is reversible, that deletion of previously created files occurs, that only 'full' backups restore everything, the two failure modes, and the returned fields. That is exactly the extra context a destructive mutation needs.

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 undo semantics and reversibility come first, then failure conditions, then return values — a logical order with no filler sentences. Every clause carries information an agent needs, and there is no repetition of the schema or annotations.

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?

For a destructive three-parameter mutation with no output schema, the definition covers reversibility, error conditions, scoping, and what the call returns. Nothing an agent needs in order to call it safely is missing.

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; the description earns an extra point by explaining the semantics of the backup argument beyond its type (a 'full' backup restores every file of the campaign) and by restating the risky meaning of allow_running in behavioral terms. Minor gap: the description does not clarify what a non-full backup restores.

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 and resource plus the exact semantics of the operation: it puts back files from the backup AND deletes files the original operation created. This precisely distinguishes it from the sibling write tool (dos2_backup) by describing the inverse operation, and the note about full backups adds scoping detail an agent could not infer from the name.

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?

Clear context: use it to undo an earlier write, and it can itself be undone via the 'before-restore' label. Gives concrete preconditions (must not be run while the game process is up unless allow_running=true; backup id must exist). It never explicitly names dos2_backup or dos2_backups as the counterpart tools, so routing is implied rather than spelled out.

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