Loading ToolBench
MCP server for the Pulse Maze Unity game, providing tools for gameplay control, observation, validation, presentation, recording, and reproducible builds. Integrates with Unity Editor and supports agent-driven testing and feature demonstrations.
Server has 6 tools with explicit schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-200 chars, baseline 194), and most parameters are typed. However, parameter descriptions are sparse or missing for critical fields (e.g., PulseMaze.Control's 'Value' and 'Number' lack context on when they apply). No output schemas documented. Error handling is minimal, most tools return generic success/failure without recovery guidance. Tool names use domain-specific verbs (Observe, Control, Validate, Present, Record) but lack clarity on mutual exclusivity and dependencies. No enum constraints on string parameters despite enumerated valid values (e.g., Action in Control accepts 'up, down, left, right, pause, resume, autopilot, debug, palette, overcharge, reset, scenario, step, capture', should be an enum). Composition is reasonable (each tool has one primary concern), but chaining is unclear (e.g., does Observe output feed into Control?).
Create a reproducible Windows x64 development build of Pulse Maze.
Control the running game with semantic actions, deterministic scenarios, resets, and fixed-frame stepping.
Read compact, machine-readable gameplay state from the running Pulse Maze scene.
Draw timed text, highlight a semantic screen region, render C# on the code canvas, or run the complete AI feature tour.
Start or stop a Game View MP4 recording, inspect recorder status, or schedule the complete AI feature tour export.
Validate maze dimensions, connectivity, spawns, and side-portal reachability without entering Play Mode.
Parameter descriptions lack context on mutual exclusivity and conditional requirements. E.g., PulseMaze.Control's 'Value' and 'Number' are only valid for specific Action values (scenario, step, reset, capture), but this dependency is not documented in parameter descriptions.
String parameters with enumerated valid values are not declared as enums. PulseMaze.Control.Action accepts 13 specific values but is typed as free-form string. LLMs will hallucinate invalid actions. PulseMaze.Present.Operation and PulseMaze.Record.Operation have the same issue.
Output schemas are not documented. Tools return anonymous objects with fields like 'success', 'message', 'observation', 'report', 'path', but LLMs cannot plan downstream calls without knowing the structure. E.g., does Observe.observation contain player_position, maze_state, sentinel_positions? Unknown.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Error handling is minimal and non-actionable. Tools return generic 'success: false' with messages like 'Pulse Maze is not in Play Mode' or 'Unknown action or scenario'. No recovery guidance (e.g., 'Enter Play Mode first' or 'Valid actions are: up, down, left, right, ...'). LLMs cannot self-correct.
Transport mechanism is UNKNOWN. Source code shows Unity Editor integration via McpTool attributes but no explicit HTTP, SSE, or STDIO transport layer visible. Cannot assess remote accessibility or protocol compliance without transport details.