hyperbox-mcp

# HyperBox **An MCP server that gives your coding agent somewhere to prove a change actually works — before it tells you it does.** Your agent says "done, tests pass." Did it actually run them? The same model that wrote the code is also the one telling you it works, with no independent check in between — which is exactly why AI-written diffs so often look right and aren't. HyperBox gives the agent somewhere to actually run the change: ``` create_sandbox() → run(code) → run(fixed code) → destroy_sandbox() ``` `run` returns real stdout, stderr and an exit code the agent didn't generate and can't talk its way around — so the agent can fix its code and try again, and "it works" stops being a claim you take on faith. As a side effect, none of this touches your machine, your files, or your credentials while it happens. ## What your agent gets Four tools, and nothing else: | Tool | What it does | |---|---| | `create_sandbox(language, backend, environment, packages, sync_from)` | A persistent, disposable container, with any declared packages installed before it is sealed, and optionally a directory of yours copied in. Returns a `sandbox_id`. | | `run(sandbox_id, code, libraries, timeout)` | Executes code. Returns `{stdout, stderr, exit_code, success, timed_out}`. | | `run(sandbox_id, code, background=True)` | Starts something that keeps running — a server, a worker — and returns a `process_id` instead of output. | | `get_process_logs(sandbox_id, process_id)` | Reads what a background run has printed. | | `destroy_sandbox(sandbox_id)` | Tears it down. Idempotent, and confirmed against the engine before claiming success. | Plus a `hyperbox://capabilities` resource publishing the exact limits, so an agent can read them instead of discovering them by failing. **Five languages** — `python`, `javascript`, `bash`, `go` and `java` — each on an official tagged image. **Declare dependencies at creation.** `packages=["requests"]` installs while the sandbox may still …