Skip to main content
Glama
RichardBennyVolt

MB2-MCP

by RichardBennyVolt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Play the scene from the editor

editor_play
Destructive

Start or stop the Modding Kit editor's test mission for the open or named saved scene, wait for player spawn or editor return, and report status or missions.

Instructions

Play mode of the Modding Kit editor (needs the bridge). start plays the open scene with the editor's test mission — the same managed entry the editor's Play button reaches; the player spawns at spawnpoint_player_test or spawnpoint_player — and waits until the player is there. It loads the scene's SAVED file: save first (start refuses when changes made through this server are newer than the file). stop returns to the editor exactly like the leave key does in play mode, and waits for it. status / missions report. While playing, live scene_* commands are refused (they act on the edited scene); use mission, navmesh_query and editor_command screenshot.

Input Schema

NameRequiredDescriptionDefault
sceneNostart: play another saved scene of the loaded modules by name instead of the open one (the editor keeps its scene).
actionNoAction (default status).
levelsNostart: scene levels for the mission, e.g. 'siege' or 'civilian' (default none).
missionNostart: the editor mission (default the first one listed by action=missions).
wait_secondsNostart/stop: wait until the player is spawned / the editor is back (default 120 / 30; 0 = return at once).
allow_unsavedNostart: play although changes made through this server since the last save are not in the file (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=true; the description adds substantial context beyond that: the bridge requirement, that it loads the SAVED file rather than live edits, the save-refusal condition, spawn point fallbacks, blocking wait behavior, and the exact semantics of stop mirroring the leave key. Nothing here contradicts the destructive/read-write annotations.

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?

Purpose is front-loaded in the first clause and every subsequent sentence carries operational information (save requirement, restrictions, alternatives). It is dense and somewhat run-on, but there is little that could be cut without losing behavioral detail.

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?

With no output schema and six optional parameters, the description covers what an agent needs: prerequisite (bridge), save-state gate, per-action semantics, waiting behavior, and which sibling tools to use during play mode. Nothing required to invoke it correctly 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 baseline is 3, but the description adds real meaning: it clarifies the saved-file constraint that motivates allow_unsaved, explains that start/stop block until the player is spawned or the editor returns (wait_seconds), and notes the scene override keeps the editor's own scene. It does not, however, restate the levels/mission enum details.

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+resource (play mode of the Modding Kit editor) and then spells out each action's effect: start plays the open scene, stop returns to the editor, status/missions report. An agent can distinguish this from editor_status, editor_launch, and scene_edit without opening the 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?

Gives explicit when-to-use ('start plays the open scene... the same managed entry the editor's Play button reaches'), a prerequisite ('save first; start refuses when changes through this server are newer than the file'), and explicit when-not/alternatives ('while playing, live scene_* commands are refused... use mission, navmesh_query and editor_command screenshot').

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

Deploy Server

Other Tools