Loading ToolBench
MCP server for dosbox-automation: drive a DOS machine from an AI agent
18 tools with explicit schemas and descriptions. Naming follows verb_noun pattern (bridge_*, cpu_*, debug_*, freeze_*) and is action-oriented. Descriptions are present and substantive (avg ~120 chars), exceeding the 20-char minimum. However, parameter descriptions are sparse: many parameters lack descriptions entirely (e.g., cpu_write_register's 'register' param has a description, but freeze_set's 'width' param description is minimal). Output schemas are not documented, LLMs cannot infer what fields to expect from responses. Error handling is implicit (no recovery guidance in descriptions). Tool composition is sound (single responsibility), but some tools like bridge_setup combine multiple concerns (port, headless, protocol). Risk annotations are present but descriptions do not always state irreversibility clearly (e.g., bridge_start says 'Spawn' but does not explicitly warn it is irreversible).
Explicitly attach to the running dosbox instance: reads the token, probes the API, negotiates the protocol version. Reports a precise reason when it cannot.
Detach from the instance; it keeps running.
One-call orientation: version, connection state, and every available tool with a one-line description.
Tail of the spawned instance's output (untrusted machine output). Only covers an instance this bridge started.
Change safe bridge settings: port, headless, protocol pin. The binary path and the capability mode are human-edited only and are rejected here by design.
Spawn the dosbox binary named in the human-edited config file (with an isolated config dir) and attach to it. Refuses while an instance is already managed.
Output schemas not documented. LLMs cannot infer response structure (fields, types, pagination). Responses must include IDs for tool chaining (e.g., bridge_connect should return engine_info with version, protocol, features).
Irreversible operations (bridge_start, bridge_stop) lack explicit confirmation or dry-run support. Descriptions do not clearly state consequences. LLMs may invoke destructively without understanding side effects.
Error handling descriptions missing. Tools do not guide LLM recovery (e.g., bridge_connect fails, should suggest 'check token' or 'verify port'). No categorization of retryable vs fatal errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Bridge and connection state: engine version, effective protocol, enabled features, capability mode, managed instance, token presence (never the value).
Stop the instance this bridge spawned. Never stops an instance it merely attached to.
Digest of the instance's OpenAPI surface: route counts per group and routes unknown to the negotiated protocol.
Bridge version and the protocol level it implements.
Write a CPU register. General registers (eax..ebp) accept 32-bit values. Segment registers (cs,ds,es,ss,fs,gs) accept 16-bit values and update the cached physical base.
Resume emulation from the current pause point.
Pause emulation at the current instruction.
Debugger state: paused, breakpoints, current instruction.
Execute one instruction and pause again.
Remove a freeze. Pass an address to remove one, or omit to clear all freezes.
List all active memory freezes.
Lock a memory address to a value. The value is rewritten every frame, trainer-style. Width is 1/2/4 bytes, little-endian.
bridge_setup combines three unrelated concerns (port, headless, protocol). Should split into separate tools (set_port, set_headless, set_protocol) for single responsibility and independent composition.
Parameter constraints not fully specified. freeze_set 'width' accepts 1/2/4 but description does not state this as an enum. cpu_write_register 'register' accepts specific names but no enum constraint. LLMs may pass invalid values.