Loading ToolBench
MCP Server for ZX84 emulator. Wraps the emulator as a persistent MCP tool server so clients can interact with a headless machine without rebuilding the harness for every call.
Critical gaps across all dimensions. The server exposes 9 tools but the provided source code does not include the actual tool registration files (mcp/tools/*.ts). The description brevity across all 9 tools is a critical blocker: each is only a generic 1-sentence placeholder, violating the baseline that 100% of A+ tool params have descriptions and 94% of A+ tools have substantive docstrings (baseline avg 194 chars, these are ~60 chars with no parameter docs).
Breakpoint management operations (from mcp/tools/breakpoints.ts register function)
I/O port operations (from mcp/tools/io.ts register function)
Machine-related operations (from mcp/tools/machine.ts register function)
Media loading/unloading operations (from mcp/tools/media.ts register function)
Memory read/write operations (from mcp/tools/memory.ts register function)
Peripheral device operations (from mcp/tools/peripherals.ts register function)
Symbol/debugging symbol operations (from mcp/tools/symbols.ts register function)
Execution trace operations (from mcp/tools/trace.ts register function)
Tool definitions not visible in source code. Server imports register functions from mcp/tools/*.ts files but those files were not provided.
All 9 tool descriptions are under 20 characters of substantive content (e.g., 'Machine-related operations (from mcp/tools/machine.ts register function)'). These generic placeholders provide no LLM-optimized guidance on WHAT the tool does, WHEN to use it, or WHAT it returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 29 | 2026-07-28+ | v2 |
Trap/watchpoint management operations (from mcp/tools/traps.ts register function)
No input schemas visible. This violates the baseline that 100% of A+ tools have documented return types and proper JSON Schema definitions.
Tool names end with '_tool' suffix (e.g., 'machine_tool', 'memory_tool'). Baseline naming: 90% of A+ tools start with action verbs (get_, list_, create_, search_, update_, delete_, send_). These names are noun-based and do not convey actions. 'memory_tool' does not signal whether the action is to read, write, dump, or analyze memory. Expected: 'read_memory', 'write_memory', 'dump_memory_range', etc.
No parameter documentation visible. Cannot verify that every input parameter has a description (baseline: 100% of A+ tools have param descriptions). Cannot confirm presence of enums, format constraints, min/max ranges, or default values. LLM must guess intended use for all parameters.
No error handling documentation visible. Cannot verify recovery guidance, error categorization (retryable/user-fixable/fatal), or actionable error messages. Per pattern:recovery-guide, errors must tell LLM what to do next, raw codes are useless.
Six tools marked with WRITE risk (machine, memory, breakpoints, traps, io, media, peripherals) but no security documentation visible. Per pattern:permission-gate, destructive operations must declare required permissions and implement access checks. No audit trail or confirmation patterns documented.
No output schema documentation. Cannot verify that tools return structured, typed objects with clear field meanings. Baseline: 100% of A+ tools document return types. Cannot confirm pagination support, result limits, or inclusion of chaining IDs needed for downstream tool calls.