Loading ToolBench
MCP server for interacting with a TempleOS VM. Lets AI agents execute HolyC code, manage files, capture screenshots, and control the VM lifecycle.
Server has 24 tools with basic descriptions and some parameter documentation, but significant gaps in schema completeness and error handling. Most tools lack input validation guidance, parameter constraints (enums, ranges), and structured output documentation. Descriptions are present but often generic (e.g., 'Stop the TempleOS VM' is only 20 chars). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Error handling returns simple strings rather than actionable recovery guidance. Parameter descriptions exist for some tools (temple_exec, temple_upload_file) but many lack detail on format/constraints. Output schemas are not documented, agents cannot plan downstream calls. Naming is generally clear (verb_noun pattern) but some tools combine multiple concerns (temple_vm_reinstall_agent does stop+reinstall+restart).
Delete a file from the TempleOS filesystem.
Execute HolyC code on TempleOS and return the captured output. timeout: seconds to wait for response (default 30). Use a lower value for untrusted code, or higher for long-running computations.
Execute HolyC code on TempleOS without waiting for output. Use this for graphics programs with infinite draw loops that would otherwise timeout. The code starts running immediately. Use temple_screenshot() to see the output and temple_send_key('esc') to exit the program. The agent will not respond to other commands until the program exits.
Upload a .HC file from the host and execute it on TempleOS. Relative paths resolve from the temple-os-claude project root. Absolute paths also work. timeout: seconds to wait for response (default 30).
Upload and run a .HC file without waiting for output. Same as temple_exec_file but returns immediately. Use this for graphics demos or programs with animation loops.
No input schemas visible for any tool. All 24 tools have Input: {} in the specification, meaning no parameter type definitions, constraints, or validation rules are declared. This violates the JSON Schema requirement and prevents LLMs from understanding valid parameter ranges, enums, or formats.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
List directory contents on TempleOS. Returns filenames with sizes.
Click at screen coordinates (640x480) by setting TempleOS mouse state directly via the serial agent (ring-0). Use temple_screenshot() first to identify click targets. Only works when the agent is responsive (not during exec_bg).
Ping the TempleOS serial agent to check if it's responding.
Read a file from the TempleOS filesystem. Example: C:/Home/Hello.HC
Return TempleOS programming reference documentation. Topics: 'setup' (VM setup guide for new projects), 'language' (HolyC syntax, types, operators), 'graphics' (CDC, drawing, 3D transforms, sprites), 'doldoc' (document system, widgets, formatting), 'system' (memory, files, tasks, input, math, sound), 'patterns' (working code examples: games, animation, menus, controls), 'architecture' (OS design, boot process, task model, window manager, debugging). Pass no topic to get a list of available docs. Pass a topic name to get that full reference document.
Capture the TempleOS VM display and return it as an image.
Send a keystroke to TempleOS via the QEMU monitor. Uses QEMU key names (e.g., 'ret', 'a', 'shift-a', 'esc').
Return system information from TempleOS (uptime, cores, etc).
Upload a file from the host to the TempleOS filesystem. Handles files of any size by chunking automatically. host_path: absolute path or relative to project root. guest_path: path on TempleOS (default: C:/Home/<filename>).
Start the VM booting from the TempleOS ISO for installation. The VM starts non-blocking so you can drive the installer via temple_send_key and temple_screenshot. See temple_reference('setup') for the exact key sequence.
Create a new TempleOS VM directory structure and blank disk image. Uses TEMPLE_OS_VM_DIR for the location (default: <project>/vm). After this, the user needs to download the TempleOS ISO to <vm_dir>/iso/TOS_Distro.ISO and run the interactive install and setup steps.
Download the TempleOS ISO to the VM directory. Skips if the ISO already exists. Required before temple_vm_boot_iso().
Install the serial agent onto the TempleOS disk image. The VM must be stopped. Run this after the interactive TempleOS install and first-boot setup, or to reinstall the agent after an update.
Stop the VM, reinstall the serial agent to disk, restart, and wait for the agent. Use this after modifying SerialAgent.HC.
Restart the TempleOS VM and wait for the agent to be ready. Handles the full cycle: stop, start, boot key, poll for agent. Returns when the agent responds to ping.
Start the TempleOS VM in headless mode (or GUI mode if TEMPLE_OS_GUI=1). After starting, send boot loader key '1' via temple_send_key, then poll temple_ping until the agent responds.
Check if the TempleOS VM is running.
Stop the TempleOS VM.
Write content to a file on the TempleOS filesystem. Example path: C:/Home/Test.HC
Multiple tools have descriptions under 20 characters (temple_vm_stop: 'Stop the TempleOS VM.' = 20 chars; temple_vm_status: 'Check if the TempleOS VM is running.' = 37 chars but minimal context; temple_screenshot, temple_ping, temple_system_info similarly sparse). These descriptions do not explain WHEN to use the tool or what it returns, violating the 10 - 1024 character guideline and LLM-optimization baseline of 50 - 200 chars.
No output schemas documented. Tools return strings or Image objects, but agents cannot see what fields are in the response, what IDs to extract for chaining, or what structure to expect. This forces agents to parse unstructured text and prevents downstream tool composition.
Error handling returns plain strings ('ERROR: ...') without recovery guidance. Per pattern:recovery-guide, errors should tell the LLM what to do next. E.g., 'File not found: C:/Home/test.txt. Use temple_list_dir("C:/Home") to see available files.' Current approach gives agents no actionable next step.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. temple_delete_file is marked DESTRUCTIVE but has no annotation. temple_vm_stop, temple_exec, temple_write_file are WRITE but unmarked. Agents cannot distinguish safe from dangerous operations without annotations.