dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Edit scene name, atmosphere, music

dos2_scene_settings

DestructiveIdempotent

Edits one GM scene's name, folder, atmosphere, ambient sound, and music in GMScenes.lsf with backup; only supplied fields change, and empty strings reset defaults.

Instructions

Changes the settings of one scene in GMScenes.lsf: its name, folder, atmosphere (lighting and weather), ambient sound and music. Only the fields you pass change; an empty string resets that field to the level's default.

It does not change what is placed in the scene: characters and items are placed in the game or with the
dos2_live_* tools. 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 scene entry as it now reads.

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>",
      "scene": "<scene>"
    },
    "name": "dos2_scene_settings"
  }
}

Input Schema

Name	Required	Description
`name`	No	New scene name. Omit to keep.
`music`	No	Music track name (GM_*). Empty string restores the level default.
`scene`	Yes	Scene name or scene ID, as listed by dos2_campaign.
`folder`	No	Folder the scene is filed under in the GM's scene list. Omit to keep.
`ambient`	No	Ambient sound name (Soundvol_*). Empty string restores the level 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.
`atmosphere`	No	Atmosphere GUID (one of the game's ATM_* atmospheres). Empty string restores the level default.
`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.

Changed8 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 / ambient / description

Added value: +"Ambient sound name (Soundvol_*). Empty string restores the level default."

addedInput schema / properties / atmosphere / description

Added value: +"Atmosphere GUID (one of the game's ATM_* atmospheres). Empty string restores the level default."

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 / folder / description

Added value: +"Folder the scene is filed under in the GM's scene list. Omit to keep."

addedInput schema / properties / music / description

Added value: +"Music track name (GM_*). Empty string restores the level default."

addedInput schema / properties / name / description
```
Added value: +"New scene name. Omit to keep."
```

addedInput schema / properties / scene / description

Added value: +"Scene name or scene ID, as listed by dos2_campaign."

First observedv0.1.0Nov 11, 2026

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the write/backup profile is partly structured. The description still adds real value beyond that: partial-update semantics ('only the fields you pass change'), empty-string-as-reset behavior, a backup taken before writing, an undo path via dos2_restore, and the running-game failure mode. Against the annotation bar this is solid, though it stops short of describing the returned entry's shape or what happens on conflicting inputs.

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?

Four short sentences, front-loaded with the scope, then the exclusion, then safety/undo, then return value. No filler and no repetition of the title.

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 an 8-parameter destructive mutation with no output schema, the description covers the essentials an agent cannot get from the schema: partial-update semantics, backup and undo, the running-game failure condition, and what the call returns (backup id plus the updated scene entry). Nothing material 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 per-parameter meanings are already fully documented, including the empty-string reset on music/ambient/atmosphere and the danger note on allow_running. The description's contribution is mainly the cross-parameter rule that omitted fields are left untouched, which the schema states only per-field; that is genuinely useful but the description largely restates schema text.

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?

The description names a specific verb and resource ('Changes the settings of one scene in GMScenes.lsf') and enumerates exactly which fields it touches: name, folder, atmosphere, ambient, music. It also explicitly carves out the neighboring concern ('does not change what is placed in the scene') and points to dos2_live_* for that, so it is separable from siblings 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?

It states the edit-vs-placement boundary and names the alternative tool family (dos2_live_*) for the other case, plus named recovery (dos2_restore) and a pre-condition on the game process running. The user-confirmation rule for allow_running is explicit, which is exactly the kind of when/when-not guidance an agent needs before a write.

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