dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Detach the bridge mod

dos2_bridge_detach

DestructiveIdempotent

Detach the bridge mod from a campaign to disable live bridge tools and remove the bridge .pak requirement; backs up the prior file for restore.

Instructions

Removes this server's bridge mod from the campaign's add-ons in meta.lsf. After that the dos2_live_* tools no longer work for this campaign, and players no longer need the bridge .pak. The .pak itself stays in the game's Mods folder, and nothing happens if the bridge was not attached.

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.
Returns the backup id and the campaign's add-on list. Attach again with dos2_bridge_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>"
    },
    "name": "dos2_bridge_detach"
  }
}

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

Changed2 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: +"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.6/5.0

Behavior5/5

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

Goes well past the destructive/idempotent annotations: it discloses the concrete effects (dos2_live_* tools stop working, players no longer need the bridge .pak), the deliberate non-effect (.pak stays in the Mods folder), the no-op case, the automatic backup, and the pre-flight failure condition while the game runs. It also names what is returned (backup id and add-on list), which the annotations do not cover.

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 effect and post-state come first, followed by recovery, failure mode, and return value – a well front-loaded structure with no filler. There is minor overlap between "players no longer need the bridge .pak" and "The .pak itself stays in the game's Mods folder", which is clarifying rather than redundant, so the cost is small.

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 two-parameter destructive mutation with no output schema, the description covers effect, side effects, reversibility, prerequisite failure mode, and return values. There is no output schema, yet the description still names what comes back, so an agent has everything needed to call it and to explain the result.

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 already 100%, so the baseline is 3; the description earns above that by tying allow_running to a concrete consequence (an error is raised while the game process runs unless it is true). The campaign parameter is only implied by "this server's ... campaign", leaving the schema to explain accepted identifier forms.

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 (removes) and a precise resource (this server's bridge mod from the campaign's add-ons in meta.lsf), including the file it edits. The scope is explicit (this campaign only) and the sibling that reverses it, dos2_bridge_install, is named, so an agent can separate it from generic mod tools like dos2_mod_install without opening the schema.

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?

Routes the agent to the counterpart operations: dos2_restore to undo the change and dos2_bridge_install to attach again. It also tells the agent that nothing happens when the bridge was not attached. It stops short of stating a proactive "use this when the user wants to stop using live-editing tools", but the context needed to pick it is clearly present.

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