Loading ToolBench
Port-addressable MCP bridge for driving running games over a debug HTTP surface: launches instances and picks their ports, discovers each game's own tool list at runtime, and drives many instances at once.
Strong tool naming (verb_noun pattern throughout) and comprehensive descriptions (avg 180 chars, well within 10-1024 range). All 12 tools have clear, actionable descriptions explaining WHAT, WHEN, and WHY. Input schemas present for all tools with type definitions. However, output schemas are entirely undocumented, no tool declares what fields it returns, forcing LLMs to infer structure. Parameter descriptions are thorough but lack explicit constraints (enums, ranges, patterns). Error handling guidance is absent; tools do not indicate retryability or recovery paths. Security considerations (credentials, permissions) not addressed in tool definitions.
Run a tool on one instance and return the result. Accepts any tool from any of that instance's toolsets, and any raw debug command it understands even if unpublished. Commands are waited on until the game reports them applied, so the state returned is the state after the command ran.
Shut this instance down through the game's own clean-exit path, and wait until the port stops answering. This is the correct way to end an instance you started: killing the process skips the game's teardown, and on a shared machine you may not know whose process you are killing.
Full schemas for the tools in one toolset on one instance. 'bridge' is the toolset this bridge adds itself; 'passthrough' explains how to send commands the game has not published.
Liveness check from GET /health. The cheapest way to confirm an instance is up and its frame counter is advancing.
The game's full JSON snapshot from GET /state. Pass summary:true for a compact digest (frame, screen, scalar game fields, visible UI labels, recent events) instead of the whole document, which for a running simulation can be very large.
Output schemas completely undocumented. No tool declares return type, field names, or structure. LLMs cannot plan downstream calls or extract required data without guessing.
Parameter constraints missing. 'timeoutMs', 'lines', 'pollMs' lack min/max bounds. 'range' parameter accepts free-form strings without format guidance. LLMs may pass invalid values (negative timeouts, absurd line counts).
No error handling guidance. Tools do not indicate which errors are retryable, which require user intervention, or how to recover. Agents cannot distinguish transient failures from permanent ones.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
The captured stdout/stderr of an instance this bridge launched. When a game fails to boot, or dies mid-session, the stack trace is here and nowhere else.
Start a game instance and wait until it answers. The bridge picks a free port itself, so you never choose one and never collide with someone else's instance, and it owns the process: it is reaped when this server shuts down. Uses the project's launch declaration (gamebridge.json). Returns the port to pass to every other tool. Prefer this over starting the game yourself.
What is running: instances that self-registered, plus a sweep of the configured port range for games that predate the registry. Reports name, version, pid, working directory, current screen and whether each was found via the registry or the scan. Read-only, so it is safe to point at instances someone else owns. Use it to attach to a game you did not launch.
List the toolsets one instance publishes, as that instance describes itself. Different ports can legitimately return different lists. Start here, then describe_toolset, then call_tool.
Send any debug command by name with arbitrary arguments, whether or not the game's manifest mentions it. The escape hatch that keeps this bridge useful against a game that is being written underneath it.
Shut down an instance this bridge launched: the game's own close command first, then termination of the process tree if it will not go. Only ever applies to a process this bridge started. To ask a game you did not launch to exit, use call_tool { name: 'close' }.
Poll GET /state until a condition holds: a field reaches a value, a field changes, or an event appears. This is how you wait for something the command that started it cannot report - a queued screenshot reaching disk, a simulation reaching frame N, a score settling. Returns whether it matched, how long it took, and the resulting digest.
Destructive tools (stop_instance, close) lack confirmation or dry-run support. Agents can terminate running instances without safeguards. No idempotency guarantees documented.
Security not addressed. No mention of permission gates, audit trails, or secret injection patterns. Tools accept arbitrary port numbers and command names without validation hints.