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

dos2-gm-mcp

by o-shabashov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Delete a vignette

dos2_delete_vignette
Destructive

Deletes a campaign vignette by UUID or exact title while preserving shared illustration files; backs up the campaign first and blocks writes while the game is running.

Instructions

Deletes one vignette from the campaign, found by UUID or exact title. Its picture files stay in the campaign's Vignettes/Illustrations folder, so other vignettes that use the same image keep working.

Writes Vignettes.lsf. 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.
Fails with an error when nothing matches. Returns the UUIDs removed and the backup id.

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>",
      "vignette": "<vignette>"
    },
    "name": "dos2_delete_vignette"
  }
}

Input Schema

NameRequiredDescriptionDefault
campaignYesThe campaign to work on: its name, its folder name, its UUID, or a unique part of any of them. dos2_status lists the campaigns.
vignetteYesThe vignette's UUID or its exact title (case-insensitive), as listed by dos2_vignettes.
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. Changed3 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: +"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 / vignette / description
      Added value: +"The vignette's UUID or its exact title (case-insensitive), as listed by dos2_vignettes."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the destructiveHint/readOnlyHint annotations: it names the file written (Vignettes.lsf), states a backup is taken first, explains that image files survive so shared illustrations keep working, documents the running-game guard, and reports the return payload. This is exactly the context an agent needs before committing a destructive write.

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?

Three short paragraphs, front-loaded with verb, resource, and lookup key, then side effects, then failure/return behavior. Dense and readable, though the no-match failure note sits awkwardly in the paragraph about the running-game guard.

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?

No output schema exists, and the description compensates by naming the return values (removed UUIDs and backup id). Combined with the undo path, backup behavior, and guard conditions, nothing material is missing for a destructive single-record delete.

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 coverage is 100%, so the schema already defines all three parameters including the allow_running warning. The description adds only the failure-on-no-match behavior tied to the vignette argument, which is a modest increment over the structured fields.

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 ("Deletes one vignette from the campaign") and further narrows the lookup key to UUID or exact title. An agent can immediately separate this from dos2_put_vignette and from the note/template delete siblings by resource alone.

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?

Gives clear operating context: it fails when nothing matches, is blocked while the game process runs unless allow_running=true, and routes the agent to dos2_restore for undo. It does not explicitly say when to choose delete versus editing via dos2_put_vignette, but the destructive intent is unambiguous.

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