dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

List characters on the live level

dos2_live_characters

Read-onlyIdempotent

List characters on the currently loaded game level, including player characters, with GUIDs and positions; filter by radius near a character to target live edits and commands.

Instructions

Lists the characters on the level currently loaded in the running game, player characters included: GUID, name, root template, stats entry, level, vitality, alignment and position. With near it returns only those within radius of that character.

Read-only; needs the game running with the bridge mod (see dos2_live_status), otherwise it fails with a timeout
error. Use it to get GUIDs and positions for dos2_live_move, dos2_live_set, dos2_live_stage and
dos2_live_spawn. For what is saved in the campaign files rather than the running game, use dos2_scene.

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

Input Schema

Name	Required	Description
`near`	No	Only list characters around this one (GUID or name). Omit to list the whole level.
`limit`	No	Maximum number of characters to return (default 200).
`radius`	No	Radius in metres around near (default 8). Ignored without near.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.1Nov 11, 2026

addedInput schema / properties / limit / description

Added value: +"Maximum number of characters to return (default 200)."

addedInput schema / properties / near / description

Added value: +"Only list characters around this one (GUID or name). Omit to list the whole level."

addedInput schema / properties / radius / description

Added value: +"Radius in metres around near (default 8). Ignored without near."

First observedv0.1.0Nov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description still adds real context beyond them: the bridge-mod requirement and the specific failure mode ('otherwise it fails with a timeout error'), which tells the agent how to interpret a non-result. It does not mention pagination/limit behaviour, keeping it short of a 5.

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-loaded with the core action and constraint, and the alternative-tool routing is crisp. The enumerated return-field list ('GUID, name, root template, stats entry, level, vitality, alignment and position') is partly redundant given the tool has an output schema, costing it a point.

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 read tool whose output schema already defines the return shape, the description covers what the schema cannot: runtime prerequisite, timeout failure mode, sibling routing for live vs. saved data, and the intended downstream tools. 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all three parameters (near, limit, radius) are already documented, including that radius is ignored without near. The description only restates the near/radius pairing ('With near it returns only those within radius of that character') and says nothing about limit or filtering semantics, so baseline 3 applies.

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 ('Lists the characters on the level currently loaded in the running game') and scopes it further ('player characters included'). It also names the return fields and explicitly contrasts itself with dos2_scene for campaign-file data, so the agent can distinguish it from the saved-data siblings without opening schemas.

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 the concrete downstream consumers ('Use it to get GUIDs and positions for dos2_live_move, dos2_live_set, dos2_live_stage and dos2_live_spawn') and an explicit exclusion with an alternative ('For what is saved in the campaign files rather than the running game, use dos2_scene'). The prerequisite (game running with bridge mod) is stated as a condition for use.

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