dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Hide or show a live character

dos2_live_stage

Idempotent

Takes a character in the running game off stage or brings it back on, keeping it in the level with its state so NPCs can be hidden temporarily or prepared for an entrance without deletion.

Instructions

Takes a character on the live level off stage or brings it back. An off-stage character is invisible and takes no part in the scene but stays in the level with its state, so this is the reversible way to remove an NPC or to prepare one for a later entrance; nothing is deleted.

Changes only the running game. Fails with an error when who matches no character or more than one (then pass a
GUID). Needs the bridge (see dos2_live_status). Returns the character's new state.

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": {
      "who": "<who>",
      "on": "<on>"
    },
    "name": "dos2_live_stage"
  }
}

Input Schema

Name	Required	Description	Default
`on`	Yes	false takes the character off stage (hidden and inactive); true brings it back.
`who`	Yes	The character to act on: its GUID, its exact name, or a unique part of its name (see dos2_live_characters).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Nov 11, 2026

addedInput schema / properties / on / description

Added value: +"false takes the character off stage (hidden and inactive); true brings it back."

addedInput schema / properties / who / description

Added value: +"The character to act on: its GUID, its exact name, or a unique part of its name (see dos2_live_characters)."

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?

Beyond the annotations (readOnly=false, destructive=false, idempotent=true), the description discloses that changes affect only the running game and not saved data, that nothing is deleted, that state is retained while off stage, that ambiguous or unmatched names raise an error, and what to do about it (pass a GUID). It even states the return value (the character's new state), which annotations and schema 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?

Two short paragraphs, front-loaded with the core behavior followed by operational caveats; every sentence carries information. Minor redundancy between "invisible and takes no part in the scene" and "nothing is deleted," but both are doing disambiguation work.

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 state-mutation tool with no output schema, the definition covers purpose, prerequisites, failure modes, persistence semantics, and the shape of the return value. An agent could invoke it correctly without consulting anything else.

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 the baseline is 3; the description earns an increment by explaining the practical consequence of the `who` lookup failing on zero or multiple matches and prescribing the GUID fallback, which is meaning the schema's "unique part of its name" wording only hints at. It adds little about the boolean `on` beyond what the schema already says.

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 opens with a specific verb and resource ("Takes a character on the live level off stage or brings it back") and immediately defines the mechanism as invisibility plus non-participation in the scene, which separates it from a move or set operation on a sibling. It also explicitly rules out deletion semantics, telling the agent this is a visibility state change rather than a removal.

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?

It names concrete when-to-use scenarios (reversibly removing an NPC, preparing an entrance) and gives the precondition that the bridge must be installed, pointing at dos2_live_status. It also warns about the identity-ambiguity failure case, though it never names a sibling tool as the alternative for the opposite operation.

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