Loading ToolBench
MCP server for controlling the BlastEM Mega Drive emulator, providing tools for ROM execution, input simulation, debugging, and video/memory inspection
BlastEM-MCP has 16 well-defined tools with consistent naming (verb_noun pattern: blastem_start, button_down, cpu_step) and clear descriptions (avg ~80 chars, all present). Input schemas are visible and properly typed with jsonschema tags. However, output schemas are NOT documented in the tool definitions, only inferred from Go struct types in handler code. Parameter descriptions are present but terse (e.g., 'controller port number, 1 or 2' lacks context on what happens if invalid). No enum constraints for button names despite a fixed set (up, down, left, right, a, b, c, x, y, z, start, mode). Error handling is minimal, no recovery guidance or actionable error messages visible in tool definitions. Tool composition is sound (each does one thing), but no pagination or result-limiting patterns for screenshot/vram_tiles outputs.
Start one managed BlastEM session with a local ROM.
Inspect the managed BlastEM process and endpoints.
Release held input and stop the managed BlastEM process.
Remove a 68000 software breakpoint.
Set a 68000 software breakpoint at a 24-bit address.
Hold a Mega Drive controller button through BlastEM's control socket.
Release a Mega Drive controller button through BlastEM's control socket.
Output schemas not documented in tool definitions. Handlers return Go structs (statusOutput, artifactOutput, vdpSnapshotOutput, etc.) but these are not exposed in mcp.Tool registration. LLMs cannot see what fields to expect from responses.
Button parameter lacks enum constraint. 'button' accepts free-form strings with description 'button: up, down, left, right, a, b, c, x, y, z, start, or mode' but no formal enum. LLMs may hallucinate invalid button names.
No error handling guidance in tool descriptions. Tools like memory_read (max 64 KiB) and breakpoint_set (24-bit address) have implicit constraints but no recovery hints if violated. LLMs receive no guidance on what to do if a call fails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2025-06-18+ | v2 |
Continue 68000 execution until a previously configured breakpoint stops it.
Read all 68000 data/address registers, status register, and PC while stopped.
Execute one 68000 instruction and wait for the stop reply.
Read up to 64 KiB from the 68000 address space while stopped.
Write hexadecimal bytes into the 68000 address space while stopped.
Release every controller button held through this MCP session.
Capture the next BlastEM-rendered frame as a PNG image.
Capture a KITVDMP1 VRAM/CRAM/VSRAM/VDP-register snapshot.
Capture VRAM and return four PNG tilesheets, one for each live CRAM palette in palette 0 through 3 order.
Parameter descriptions are terse and lack context. 'controller port number, 1 or 2' does not explain what happens if an invalid port is passed, or whether ports are 0-indexed or 1-indexed. Descriptions should be 50-200 chars with actionable constraints.
No pagination or result-limiting patterns for image-returning tools. screenshot and vram_tiles return PNG artifacts but no indication of size limits, retry behavior, or what happens if rendering fails. Large images could exhaust context.