dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Download LSLib (one-time setup)

dos2_fetch_lslib

Idempotent

Downloads the official LSLib release, verifies its pinned SHA-256, and unpacks Divine.exe into the server data folder so campaign file tools work when divine_found=false.

Instructions

One-time setup: downloads the official LSLib release by Norbyte (Divine.exe, MIT license) from GitHub, verifies its pinned SHA-256 and unpacks it into the server's data folder. Every tool that reads or writes campaign files needs Divine.exe, so run this when dos2_status reports divine_found=false.

Needs internet access. Writes only into the data folder; the game and the campaigns are not touched. When
Divine.exe is already there it returns at once without downloading. Returns {result, source}, or {error} on a
network failure or checksum mismatch (then nothing is unpacked).

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_fetch_lslib"
  }
}

Input Schema

Name	Required	Description	Default
`force`	No	Download and unpack again even when Divine.exe is already present. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Nov 11, 2026

addedInput schema / properties / force / description

Added value: +"Download and unpack again even when Divine.exe is already present. Default false."

First observedv0.1.0Nov 11, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false): discloses internet requirement, write scope limited to the data folder with game/campaigns untouched, the idempotent early-return, checksum verification, and that nothing is unpacked on failure. Return shape {result, source} / {error} is spelled out despite no output schema.

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 tight sentences: what it does, when to run it, side effects and failure behavior. Front-loaded with the action and setup framing, zero filler.

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?

A one-parameter setup tool with no output schema, and the description covers prerequisites, write scope, idempotency, failure modes, and return shape. Nothing an agent needs in order to call it correctly 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% and the single 'force' parameter is documented there, so the baseline is 3. The description adds real meaning by stating that an existing Divine.exe causes an immediate no-download return, which is precisely the condition 'force' overrides.

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 specific verb and resource: downloads the official LSLib release by Norbyte (Divine.exe), from GitHub, verifies SHA-256, unpacks into the data folder. An agent knows exactly what artifact is produced and where it lands, 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 Guidelines5/5

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

Gives an explicit trigger condition tied to a named sibling: run this when dos2_status reports divine_found=false. It also states the pre-condition under which it is unnecessary (Divine.exe already present), so the agent can decide not to call it.

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