dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Attach or detach a .pak add-on

dos2_addon

DestructiveIdempotent

Attach or detach a ready-made .pak mod as a campaign add-on, copying it into the Mods folder, reading its metadata, and backing up meta.lsf before changes.

Instructions

Attaches a ready-made mod from a .pak file to the campaign as an add-on, or detaches it with attach=false. On attach the file is copied into the game's Mods folder; UUID, name, version and folder are read from the meta.lsx inside the pak. Detaching leaves the .pak in Mods.

Writes meta.lsf. The previous file is backed up first; undo with dos2_restore. Fails with an error while the game process is running unless allow_running=true.
Players need the same .pak, as with any add-on. Fails if the file is missing or holds no single meta.lsx.
Returns the module name, author, UUID, the .pak path and the campaign's add-on list. To build a mod from a
source folder use dos2_mod_install.

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

Input Schema

Name	Required	Description
`pak`	Yes	Absolute path to the mod's .pak file.
`attach`	No	true (default) attaches the mod; false removes it from the campaign's add-ons.
`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.

Changed4 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 / attach / description

Added value: +"true (default) attaches the mod; false removes it from the campaign's add-ons."

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."

addedInput schema / properties / pak / description

Added value: +"Absolute path to the mod's .pak file."

First observedv0.1.0Nov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructive=true and idempotent=true, but the description goes well beyond them: it discloses the file copy into the Mods folder, that meta.lsx inside the pak is parsed for UUID/name/version/folder, that meta.lsf is rewritten with a backup taken first, that detaching leaves the .pak in place, and the exact error conditions (game running, missing file, no single meta.lsx). That is substantive mutation-side context annotations cannot convey.

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?

Content is dense and front-loaded: the verb, the copy behavior, then the side effects, then failure modes, then the sibling cross-reference. Every sentence carries information, though the line breaks fragment the flow and the return-value sentence could sit more naturally with the effects paragraph.

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?

With no output schema, the description still enumerates the return payload (module name, author, UUID, .pak path, campaign add-on list), plus backup/undo, multiplayer parity, and failure modes. Nothing an agent needs to call this destructive write tool 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, but the description adds real meaning: attach=false is described as removal from the campaign's add-ons, and the pak parameter gains a constraint (must contain exactly one meta.lsx, else it fails) that the schema does not state. The campaign and allow_running semantics are largely restated from the schema, but the added pak constraint justifies a step above baseline.

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 precise verb pair and resource: attaches a ready-made mod from a .pak as an add-on, or detaches it with attach=false. It explicitly differentiates from the sibling dos2_mod_install ('to build a mod from a source folder'), so an agent can route correctly 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternatives and the conditions that select them: dos2_mod_install for source folders, dos2_restore for undo, dos2_status for listing campaigns. It also states the precondition for allow_running (game in main menu) and the failure condition while the game is running, which is exactly the when-to-use guidance an agent needs.

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