dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Delete a saved template

dos2_delete_template

Destructive

Deletes a saved NPC or item template by name from a campaign, backing up the file first. Characters already placed from that template remain unchanged.

Instructions

Deletes a saved NPC or item template from the campaign by name. If an NPC template and an item template share the name, both are removed. Characters already placed in scenes from that template stay as they are.

Writes Eggs.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 no template has that name. Returns the number of templates 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>",
      "name": "<name>"
    },
    "name": "dos2_delete_template"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Exact template name (case-insensitive), as listed by dos2_templates.
`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.

Changed3 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."

addedInput schema / properties / name / description

Added value: +"Exact template name (case-insensitive), as listed by dos2_templates."

First observedv0.1.0Nov 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare destructive=true, but the description goes well beyond them: it discloses the file written (Eggs.lsf), that a backup is taken first, the undo path, the running-game failure mode and the allow_running escape hatch, the no-match error, and the fact that characters already placed in scenes are unaffected. This is exactly the collateral-damage context an agent needs before a destructive call.

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 action and the ambiguity resolution, then moves into side effects and failure modes in short declarative sentences. Slightly fragmented from line breaks, but every sentence carries information and none is 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?

For a destructive, non-idempotent, three-parameter tool with no output schema, the description covers side effects, backups, undo, gating conditions, error behavior, and even the return payload (count and backup id). Nothing an agent needs to invoke it safely is missing.

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 baseline is 3 and the schema already explains name case-insensitivity, campaign resolution, and allow_running. The description adds real value only on the name parameter by warning that a shared NPC/item name deletes both, which the schema does not say; it adds nothing new about campaign or allow_running.

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 a saved NPC or item template from the campaign by name") and clarifies the scope precisely, including the ambiguous case where both template types share a name. An agent can distinguish it from dos2_delete_note or dos2_delete_vignette without opening any 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?

Gives clear operational context: it names the failure modes (no such template, game process running), points to dos2_restore for undo, and references dos2_templates as the way to discover names. It does not explicitly contrast against overwriting via dos2_put_npc_template/dos2_put_item_template as an alternative, so it stops short of full when-not guidance.

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