dos2-gm-mcp

Overview Schema Source Related Servers Discussions Admin

Rename, level up or re-align a live character

dos2_live_set

Idempotent

Modify a live character's displayed name, level, or alignment in the running Divinity: Original Sin 2 game without editing campaign files; only supplied fields change.

Instructions

Changes a character that already stands on the live level: its displayed name, its level and its alignment towards the party. Only the fields you pass change.

Changes only the running game, not the campaign files or the template the character came from. Setting
alignment to "Evil NPC" makes the character hostile, which can start combat. 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. To move a character use dos2_live_move; to hide one use dos2_live_stage.

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

Input Schema

Name	Required	Description
`who`	Yes	The character to act on: its GUID, its exact name, or a unique part of its name (see dos2_live_characters).
`name`	No	New name shown above the character's head. Omit to keep.
`level`	No	New level. Levels can only go up; a lower value is ignored by the game. Omit to keep.
`alignment`	No	"Neutral NPC", "Evil NPC" (hostile to the party) or "Good NPC" (ally). Omit to keep.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.1.1Nov 11, 2026

addedInput schema / properties / alignment / description

Added value: +"\"Neutral NPC\", \"Evil NPC\" (hostile to the party) or \"Good NPC\" (ally). Omit to keep."

addedInput schema / properties / level / description

Added value: +"New level. Levels can only go up; a lower value is ignored by the game. Omit to keep."

addedInput schema / properties / name / description

Added value: +"New name shown above the character's head. Omit to keep."

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.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, and the description adds real value beyond that: the change affects only the running game and not campaign files or templates, the 'Evil NPC' alignment can trigger combat, and ambiguity produces an error. However it omits anything about setting a name that collides with an existing character, and just restates the omittable-field behavior the schema already covers.

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 kept to two short paragraphs, each sentence carrying information (scope of effect, combat side effect, error/precondition, alternatives). Minor redundancy between 'Only the fields you pass change' and the schema's repeated 'Omit to keep' descriptions keeps it from a 5.

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 4-parameter mutation with no output schema, the definition covers scope of effect, side effects, error behavior, prerequisites and sibling routing, and notes it returns the character's new state. Nothing an agent needs in order to call it safely 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 the baseline is 3; the description earns a bump by explaining the consequence of the alignment enum ('makes the character hostile, which can start combat') and by stating that only passed fields change. It adds little on 'who' beyond what the schema says about GUID vs. name matching, so it is not fully additive.

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?

Names a specific verb and resource ('changes a character that already stands on the live level') and enumerates the three mutable fields (name, level, alignment). The closing sentence explicitly routes move and hide intents to dos2_live_move and dos2_live_stage, so an agent can separate this from siblings without reading 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States when to use it (character already on the live level), when not (moving, hiding — with the specific alternative tool named for each), the prerequisite (needs the bridge, pointing to dos2_live_status), and the failure condition plus remedy (ambiguous 'who' → pass a GUID). Nothing about selection is left to inference.

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