MB2-MCP

Act in the running mission

mission

Destructive

Inspect and control a live Mount & Blade II play session: check player state and nearby usable objects, walk routes with game AI, teleport, use objects, and dismount riders.

Instructions

In play mode (editor_play) or another running mission (needs the bridge): status (player position, direction, mission state); objects (usable objects near the player — doors, chairs, passages, ladders… — and whether the player can use them); dismount (the editor's test mission spawns a horseman); walk (the player walks a route with the game's own AI movement on the navigation mesh, never teleported, and each leg reports reached / stuck / timed out with the closest approach; the position trace is saved as JSON — evidence that a route can be walked, or where it is blocked); walk_status / walk_stop; teleport (positioning before a test, reported as such — not evidence of a walkable route); use (use an object within reach, the same callback as the interaction key); stop_using.

Input Schema

Name	Required	Description
`tag`	No	use: tag of the usable object's entity.
`speed`	No	walk: maximum speed limit for the player while walking (default: unchanged).
`action`	No	Action (default status).
`entity`	No	use: name of the usable object's entity (or of its parent).
`points`	No	walk: targets in order, [[x, y, z], …].
`radius`	No	objects: search radius in meters (default 10).
`position`	No	teleport: target; objects: search center (default the player).
`direction`	No	teleport: direction to face.
`tolerance`	No	walk: a target counts as reached within this horizontal distance in meters (default 0.5).
`trace_file`	No	walk/walk_status: where to save the JSON trace (default: Documents/Mount and Blade II Bannerlord/MB2MCP/walk_<id>_<time>.json).
`leg_timeout`	No	walk: seconds allowed per leg (default 30).
`max_distance`	No	use: how far the player may be from the object, in meters (default 3).
`wait_seconds`	No	walk: wait for the result up to this long (default 120; 0 = return at once and poll with walk_status).
`allow_mounted`	No	walk: test the route on horseback when the player is mounted (default false: dismount first).
`stall_seconds`	No	walk: a leg fails as 'stuck' after this many seconds without 0.3 m of progress (default 6).
`return_to_start`	No	walk: afterwards walk the route back to where the player started (default false).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 16, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, so the agent already knows this mutates state. The description adds valuable behavior for walk (per-leg reached/stuck/timed out, closest approach, JSON trace location) and that teleport is cosmetic. However it never explains what the destructive actions change or need (dismount/use/stop_using side effects, bridge/auth requirements), leaving the destructive profile under-described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single run-on sentence with stacked parentheses covering nine actions is hard to parse and not front-loaded by action. The content is dense rather than padded, but the structure works against quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 16 parameters, the description compensates by describing what status returns (position, direction, mission state), what objects returns (usable objects and whether usable), and what walk produces. Coverage of the secondary actions is thinner, but the core workflows are adequately explained.

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 description coverage is 100% across 16 parameters, so the schema already defines every field including defaults. The description adds only high-level semantics (walk vs teleport, walk reports) rather than per-parameter meaning. Baseline 3 is appropriate when the schema carries the parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific tool role (acting inside the running mission) and enumerates each action with its effect: status, objects, walk, teleport, use, dismount, etc. It distinguishes itself from siblings by requiring play mode (editor_play) or another running mission via the bridge. The laundry-list form makes it verbose but the verbs and resources are concrete.

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 states the operating precondition ('In play mode (editor_play) or another running mission (needs the bridge)') and draws a meaningful discrimination between walk and teleport: walk is 'evidence that a route can be walked', teleport is 'positioning before a test ... not evidence of a walkable route'. No explicit exclusions or when-not guidance beyond that.

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

Act in the running mission

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools