dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Back up the whole campaign

dos2_backup

Creates a full labeled backup of an entire campaign folder without changing it, safe while the game runs, for snapshots before risky edits or play sessions. Returns the backup ID and path.

Instructions

Copies the entire campaign folder into the backups folder as a new backup labelled "full". Nothing in the campaign changes, and it is safe while the game is running.

Every write tool already backs up the files it touches, so use this for a complete snapshot before a risky
series of edits or before a play session. Returns the backup id and its path. List backups with dos2_backups
and bring one back with dos2_restore.

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>"
    },
    "name": "dos2_backup"
  }
}

Input Schema

Name	Required	Description	Default
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Nov 11, 2026

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?

Beyond the annotations, the description discloses that the campaign is unmodified, that the operation is safe while the game runs, and that it returns a backup id and path. The phrase "as a new backup" also makes the non-idempotent, accumulating nature clear, which is consistent with idempotentHint=false.

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?

Three short sentences: the action and its safety profile first, then the guidance, then the return value and next steps. Nothing is padded and the most decision-relevant line leads.

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 one-parameter tool with no output schema, the description covers the operation, its side effects, its return value, and the natural follow-up tools. An agent has everything needed to call it correctly and decide whether to call it at all.

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?

There is a single parameter with 100% schema description coverage, and the schema already explains accepted identifier forms (name, folder name, UUID, unique fragment) and points at dos2_status. The description adds only the notion of scope ("entire campaign folder"), so baseline 3 applies.

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 names a concrete operation on a concrete resource: copying the entire campaign folder into the backups folder as a new backup labelled "full". It also implicitly separates itself from the listing tool (dos2_backups) and the restore tool (dos2_restore), both named explicitly.

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 states when to use it ("before a risky series of edits or before a play session") and, importantly, when it is redundant, noting that every write tool already backs up the files it touches. It also routes to alternatives by name: dos2_backups to list, dos2_restore to revert.

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