Loading ToolBench
Control emulated and physical MSX computers through MCP. Speaks MCP (JSON-RPC 2.0) over newline-delimited stdio. Can drive isolated openMSX through its control channel or physical MSX through resident Z80 monitor and TCP/serial transport. Models can upload Z80 builds, inspect/patch RAM/VRAM, control execution and render screenshots.
MSX-AI provides 44 tools with explicit schemas and descriptions, but quality is inconsistent. Most tools have basic descriptions (20-100 chars) and proper JSON Schema with enums where appropriate. However, many descriptions lack actionable context for LLM selection, parameter relationships are undocumented, and error handling guidance is absent. Tool naming follows verb_noun convention well (msx_local_boot, msx_memory_read), but composition issues exist: msx_local_* and msx_* variants duplicate functionality without clear distinction. Output schemas are not documented. No evidence of recovery guidance or error categorization. STDIO transport caps protocol readiness at 50.
Connect to a physical MSX agent via TCP or serial
Listen for incoming connections from a physical MSX agent on a TCP port
Load an application from a manifest
Assemble and load Z80 assembly code
Execute a command on the target
Capture the current CPU state (registers, flags, PC, SP)
Write text to a file on disk
Duplicate tool variants (msx_local_* vs msx_*) without clear distinction. LLMs cannot determine when to use msx_local_status vs msx_status, msx_local_screen vs msx_screen. This violates single-responsibility and composition patterns.
Most descriptions are under 50 characters and lack actionable context. E.g., 'Query the current state of the local openMSX channel' does not explain WHEN to call it, what it returns, or how it differs from msx_status. Descriptions should be 50-200 chars with selection context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2025-06-18+ | v2 |
Search the MSX-AI documentation
Validate MSX-AI setup and diagnose issues
Assemble and run Z80 code under MSX-DOS
Download a file from the target
Upload a file to the target
Read from an I/O port
Write to an I/O port
Press a key on the target
Attach to an existing openMSX instance by socket path
Boot openMSX with a specified profile (basic, disk, dos, msx2plus, cbios, auto)
Validate openMSX executable, transport, profile and config readiness without launching it
Capture the current MSX screen as text
Capture the current MSX screen as a PNG image
Query the current state of the local openMSX channel
Select a mapper page
Read a range of bytes from RAM or VRAM
Write a range of bytes to RAM or VRAM
Pause execution on the target
Listen for connections from a physical MSX
Reboot the target
Reset the target without rebooting
Resume execution on the target
Run BASIC code on the target
Run a BASIC file from disk
Capture the current MSX screen as text
Capture the current MSX screen as a PNG image
Shut down the MCP server and all targets
Select a cartridge slot
Query the current state of the selected target
Stop the target and disconnect
Query the status of all available targets (local, agent, bench)
Shut down the current bench simulation
Start a paired simulation with openMSX and agent on the same machine
Query the status of the current bench simulation
Type text into the target
Type a line of text and press Enter
Type multiple lines of text
No output schemas documented. Tools like msx_memory_read, msx_cpu_snapshot, msx_screenshot return data but LLMs cannot infer structure. Responses must document field names, types, and whether pagination is supported.
No error handling guidance. Tools like msx_local_boot, msx_agent_connect, msx_asm_load can fail but descriptions do not explain recovery steps. E.g., 'If boot fails, check profile enum or call msx_local_doctor first.'
Parameter relationships undocumented. E.g., msx_agent_connect accepts endpoint as 'oneOf' [ipv4, port] or string (serial path), but descriptions do not explain when to use each. Conditional parameter logic must be explicit.