Skip to main content
Glama
Sign In
dos2-gm-mcp

dos2-gm-mcp

by o-shabashov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Build and attach the bridge mod

dos2_bridge_install
DestructiveIdempotent

Builds the bridge mod .pak into the game's Mods folder and optionally attaches it to a campaign's add-ons. Required for the live game tools to work.

Instructions

Builds this server's bridge mod into the game's Mods folder (DOS2GMBridge_....pak, overwriting the previous build) and, when campaign is given, adds it to that campaign's add-ons in meta.lsf. The bridge is what the dos2_live_* tools talk to; it needs Script Extender in the game.

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.
In multiplayer every player needs the same .pak and Script Extender, as with any add-on; after a rebuild, send
them the new file. Returns the .pak path, the packed files and the campaign's add-on list. Check the result
with dos2_live_status; remove with dos2_bridge_detach.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "dos2_bridge_install"
  }
}

Input Schema

NameRequiredDescriptionDefault
campaignNoCampaign to attach the bridge to as an add-on (name, folder, UUID or a part). Omit to only build the .pak.
allow_runningNoKeep 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.

  1. Changed2 schema fields changedv0.1.1
    • 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 bridge to as an add-on (name, folder, UUID or a part). Omit to only build the .pak."
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds real substance beyond them: the previous .pak is backed up first, an existing build is overwritten, and writes into a loaded campaign can be lost or damage it. It also discloses the multiplayer requirement that every player needs the same .pak plus Script Extender, which no annotation conveys.

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?

Front-loads the build behavior and the campaign attach, then the safety and lifecycle notes. It is dense with no filler sentences, though the trailing returns/check/remove list is slightly tacked-on rather than woven into the flow.

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?

No output schema exists, and the description compensates by naming the return payload (the .pak path, packed files, and the campaign's add-on list). Combined with the backup, overwrite and running-game caveats, an agent has what it needs to call this correctly.

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 baseline is 3, but the description adds meaning beyond the schema by tying campaign to the add-on list in meta.lsf and by stating the consequence of allow_running (a write into a loaded campaign gets lost or damages it). It does not add new format detail for how campaign values are matched, leaving that to the schema.

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?

Names a specific verb and artifact: builds the bridge mod into the game's Mods folder as DOS2GMBridge_....pak and optionally attaches it to a campaign's add-ons in meta.lsf. That is clearly distinguishable from dos2_bridge_detach, dos2_mod_install and the dos2_live_* tools it feeds.

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?

Gives explicit routing: undo with dos2_restore, verify with dos2_live_status, remove with dos2_bridge_detach, and omit campaign to only build the .pak. It also states the precondition for allow_running and the failure mode when the game is running without it.

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