Loading ToolBench
Model Context Protocol server for Mindustry game integration, enabling AI to interact with Mindustry instances via logic processors, schematics, and game state queries
Server has 15 tools with explicit schemas and descriptions. Naming follows verb_noun convention (game_connect, processor_read, mlog_validate). Descriptions are present and contextual (avg ~120 chars), meeting baseline minimums. However, parameter descriptions are sparse or missing entirely, most numeric params (x, y) lack range/constraint documentation. Output schemas are undocumented; responses are JSON-serialized but structure is opaque to the LLM. Error handling returns isError=true with text but lacks recovery guidance or categorization. No tool annotations (readOnlyHint/destructiveHint). Security: no secrets in params (good), but no permission gates or audit trail patterns visible.
Connect to a running Mindustry instance with the MCP companion mod loaded. The mod must be running and listening on the specified port (default 9876).
Disconnect from the running Mindustry instance.
Read a property from a block at given coordinates. Properties: @health, @maxHealth, @totalItems, @copper, @lead, etc. Requires game connection.
Get the current game status: map name, wave number, core resources, etc. Requires an active connection to the game.
List ALL logic blocks on the map: processors (with code info), messages (with text), memory cells/banks (with size), switches (with state), and displays. Requires game connection.
Read the text content of a message block at given coordinates. Useful for reading processor output. Requires game connection.
Numeric parameters (x, y, port) lack range/constraint documentation. LLMs cannot infer valid bounds, e.g., are x/y tile coordinates (0-255) or pixel offsets? Is port 1-65535 or game-specific?
Output schemas are completely undocumented. Tools return JSON via TextContent but LLMs cannot plan downstream calls without knowing response structure (e.g., does game_status return {map, wave, resources} or {status: {map, wave, ...}}?).
Error responses lack recovery guidance. CallToolResult(isError=true) with plain text does not tell LLM whether to retry, ask user, or abort. No error categorization (retryable vs user-fixable vs fatal).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Get mlog code templates for common tasks. Available templates: sorter (item sorting), turret-control (auto-targeting turret), unit-mine (mining with units), display-text (text on display), resource-monitor (monitor resource levels), unit-patrol (unit patrol route).
Get reference documentation for Mindustry Logic (mlog) instructions. Query can be: an instruction name (e.g. 'op', 'sensor'), a category ('io', 'block', 'operation', 'flow', 'unit'), or a special topic ('ops', 'sensors', 'processors'). Leave empty for full reference.
Validate Mindustry Logic (mlog) code. Checks for syntax errors, unknown instructions, wrong argument counts, invalid op operations, and invalid jump conditions.
List all logic processors on the current map. Returns type, position, and whether they have code. Requires game connection.
Read the mlog code from a processor at the given coordinates. Requires game connection.
Write mlog code to a processor at the given coordinates. Requires game connection.
Add a processor with mlog code to an existing schematic. Takes a base64 schematic and returns a new base64 with the processor added.
Create a Mindustry schematic (.msch) with blocks and processors. Returns a base64 string that can be imported into Mindustry via clipboard. Each block needs a type, x, y position. Processors also need mlog code. Block types include: micro-processor, logic-processor, hyper-processor, message, memory-cell, memory-bank, logic-display, large-logic-display, switch, conveyor, router, sorter, duo, scatter, hail, salvo, etc.
Read and parse a Mindustry schematic from base64 string. Shows all blocks, their positions, and processor code if present.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). processor_write is destructive but unmarked; game_disconnect has side effects but no annotation. LLMs cannot distinguish safe reads from risky writes.
Parameter 'property' in game_sensor accepts free-form strings (@health, @copper, etc.) but no enum or validation. LLMs will hallucinate invalid property names. Should enumerate valid properties or validate server-side with clear error messages.