The README is unusually candid about the edges: there are no `fs` or `process` modules, each run starts from a clean VM so nothing persists between calls, and module filtering is configurable but the runtime enforcement is described as not fully implemented. Read that last one as: treat the flags as intent, not as a security boundary. What you do get is a genuinely capable scratchpad — network calls, hashing, binary handling — with no key to provision.
A Go MCP server exposing one tool that runs JavaScript in a modern runtime. The environment is assembled from named modules: fetch, timers, buffer, encoding and url are global, while crypto, cache and an HTTP server come in through `require`. Each execution starts in a clean VM.
- `executeJS` — takes a `code` string and runs it, with `console.log`, `console.error` and `console.warn` captured
- Modern `fetch` with Request, Response, Headers and FormData available globally, so a script can call an API without extra setup
- Crypto through `require('crypto')` — hashing, encryption and HMAC
- An in-memory cache with TTL support through `require('cache')`, and an HTTP server through `require('http/server')`
- Buffer, Blob and File for binary data, plus TextEncoder/TextDecoder and URL/URLSearchParams
- Module selection at launch: `--enabled-modules` to allow only some, `--disabled-modules` to turn specific ones off
Nothing beyond the binary: `go install github.com/mark3labs/codebench-mcp@latest`, then run `codebench-mcp`, or pull `ghcr.io/mark3labs/codebench-mcp:latest` and run it in Docker. No API key and no account. Execution timeout defaults to 5 minutes and is set with `--execution-timeout` in seconds. It can also be embedded as a library in a Go project, including over an in-process transport.
One command — go install github.com/mark3labs/codebench-mcp@latest