Skip to main content
Glama

Install the editor bridge

editor_bridge_install
Destructive

Compile the MB2-MCP editor bridge against your installed game and install it so live tools can inspect and edit the open Modding Kit scene. Re-run after game updates.

Instructions

Compiles the MB2-MCP editor bridge (a small C# module) against your installed game with the Windows .NET compiler and installs it as Modules/MB2MCP.EditorBridge. Inside the Modding Kit editor it lets the live tools (scene_* live=true, editor_command) inspect and edit the open scene. Re-run after game updates.

Input Schema

NameRequiredDescriptionDefault
forceNoRecompile even if the current version is installed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds real prerequisites (installed game, Windows .NET compiler, recompile after updates) but never says what the destructive action overwrites or whether an existing bridge is replaced without confirmation. Useful additions, but the mutation semantics remain thin.

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?

Three sentences, front-loaded with the action and install location, with no filler. The parenthetical about scene_* live tools is dense but earns its place by linking the bridge to sibling tools.

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?

For an installer with one optional boolean parameter, no output schema, and annotations covering safety, the description supplies the important missing context: the required toolchain, the install target, and the update re-run rule. Failure modes and whether a restart is needed are not covered, keeping it below 5.

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% and the single 'force' parameter is fully documented in the schema. The description adds no meaning beyond it, so the baseline 3 for a fully-covered schema 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?

The description states a specific verb (compiles ... and installs) plus the exact artifact and install path (Modules/MB2MCP.EditorBridge), and names what the module enables. This is clearly distinguishable from every sibling, none of which install a bridge.

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 gives a clear trigger ('Re-run after game updates') and explains the enabling condition for the live tools, which is context an agent needs. It stops short of stating when not to run it (e.g. if the editor is running or the bridge is already current), so not a full 5.

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