dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Build a mod folder and attach it

dos2_mod_install

DestructiveIdempotent

Packs a mod source folder into a .pak in the game's Mods folder, replacing the previous build, and optionally attaches it to a campaign's add-ons.

Instructions

Packs your own mod from a source folder into the game's Mods folder as .pak (overwriting a previous build) and, when campaign is given, adds it to that campaign's add-ons. UUID, name, version and folder come from the mod's meta.lsx.

Use it for mods you develop yourself; for a ready third-party .pak use dos2_addon, and for this server's bridge
use dos2_bridge_install. Fails if PublishVersion in meta.lsx is below a Definitive Edition editor version (use
909321303): the game would mark the mod as Classic and refuse it. The previous file is backed up first; undo with dos2_restore. Attaching: Fails with an error while the game process is running unless allow_running=true.
Returns the .pak path, packed files, module name and UUID, and the add-on list.

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": {
      "source": "<source>"
    },
    "name": "dos2_mod_install"
  }
}

Input Schema

Name	Required	Description
`source`	Yes	Absolute path to the mod's source folder; it must contain exactly one Mods/<mod folder>/meta.lsx.
`campaign`	No	Campaign to attach the mod to as an add-on (name, folder, UUID or a part). Omit to only build the .pak.
`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 / campaign / description

Added value: +"Campaign to attach the mod to as an add-on (name, folder, UUID or a part). Omit to only build the .pak."

addedInput schema / properties / source / description

Added value: +"Absolute path to the mod's source folder; it must contain exactly one Mods/<mod folder>/meta.lsx."

First observedv0.1.0Nov 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the concrete mechanics behind them: an existing build is overwritten, the previous file is backed up first, and the undo path is dos2_restore. It further discloses two distinct failure modes (low PublishVersion causing Classic-mod rejection; attaching while the game runs unless allow_running=true) plus the return payload, which annotations cannot express.

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 opening sentence front-loads the core action and artifact before any caveats, and each subsequent sentence carries distinct routing, failure-mode, or safety information with no filler. It runs long and the attach-failure sentence slightly restates the allow_running schema text, which keeps it just short of 5.

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, multi-effect tool with no output schema, the description covers the action, the conditional attach behavior, both failure modes, the backup/undo path, and the return shape (.pak path, packed files, module name/UUID, add-on list). Nothing an agent needs 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.

Parameters3/5

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

Schema description coverage is 100% and the schema text already covers all three parameters in depth (including the 'Keep false' wording for allow_running), so the baseline is 3. The description reinforces parameter behavior by framing campaign as 'adds it to that campaign's add-ons' and tying allow_running to a concrete runtime failure, but it does not add syntax, defaults, or resolution rules beyond what the schema states.

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?

"Packs your own mod from a source folder into the game's Mods folder as <mod folder>.pak" names a specific verb, a specific source, and the exact output artifact, plus the conditional campaign-attach side effect. It explicitly names the two siblings it partitions space with (dos2_addon, dos2_bridge_install), so an agent can route without opening any other 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?

"Use it for mods you develop yourself; for a ready third-party .pak use dos2_addon, and for this server's bridge use dos2_bridge_install" gives an explicit when-to-use plus two named alternatives with the condition that selects each. It also states a hard preclusion (fails if PublishVersion is below Definitive Edition) and the running-game precondition for attaching.

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