MCP server for ScratchRun — ephemeral, MicroVM-isolated code execution for AI agents.
Each call runs in a fresh hardware-isolated MicroVM. The VM is hard-purged after execution. No state, no files, nothing persists between calls.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"scratchrun": {
"command": "npx",
"args": ["-y", "@scratchrun/mcp-server"],
"env": {
"SCRATCHRUN_API_KEY": "sr_live_your_key_here"
}
}
}
}Get an API key at scratchrun.dev.
Related MCP server: Code Executor MCP Server
scratchrun_execExecutes code in an ephemeral sandbox and returns stdout, stderr, exit code, and any output files.
Parameters:
Parameter | Type | Required | Description |
|
| yes | Runtime to use |
| string | yes | Code to execute |
| integer | no | Timeout in ms (default 10000, max 30000) |
| integer | no | Memory limit in MB (default 256, max 512) |
| object | no | Environment variables — use for secrets, not code strings |
| object | no | Files to write before execution (path → content) |
| string[] | no | File paths to capture after execution (returned as base64) |
Example — run Python and return a chart:
{
"runtime": "python3.12",
"code": "import matplotlib.pyplot as plt\nimport numpy as np\nx = np.linspace(0, 10, 100)\nplt.plot(x, np.sin(x))\nplt.savefig('/tmp/plot.png')",
"return_files": ["/tmp/plot.png"]
}Output files are returned as base64. Image files (PNG, JPG, SVG) are returned as MCP image content blocks and render inline in Claude.
Hardware-virtualized MicroVM per execution (own kernel, not a shared-kernel container)
TerminateMicroVM called unconditionally after every run — VM destroyed, never reused
RFC 1918 + cloud metadata (169.254.x.x) always blocked at the network layer
Read-only system filesystem via OverlayFS; /tmp is RAM-backed and gone with the VM
~400ms median (warm pool). 2–8s cold start if the pool is empty.
MIT
Execute code in an ephemeral, MicroVM-isolated sandbox. The VM is hard-purged after execution — no state, no files, nothing persists between calls. Full internet egress (RFC 1918 + cloud metadata always blocked). Use return_files to capture output artifacts (charts, CSVs, data files) as base64. Keep secrets out of code strings — pass them via env instead.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | Environment variables injected into the sandbox. Use for secrets and config. | |
| code | Yes | Code to execute. | |
| files | No | Files to write before execution. Keys are absolute paths, values are file contents. | |
| runtime | Yes | Runtime. python3.12 includes numpy, pandas, matplotlib, requests, and more. | |
| memory_mb | No | Memory limit in MB. | |
| timeout_ms | No | Execution timeout in milliseconds. Exit code 124 signals timeout. | |
| return_files | No | File paths to capture after execution and return as base64. Use for charts, CSVs, or any output artifact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels: it discloses hard-purge/no persistence, full internet egress with RFC 1918/cloud metadata blocks, and how to retrieve artifacts. This is rich behavioral context beyond basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose. Every sentence adds value—covering security, persistence, file capture, and secrets—without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description provides comprehensive context: execution environment, security boundaries, state persistence, artifact retrieval, and secrets handling. It addresses the tool's complexity and likely pitfalls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds extra meaning by explaining the purpose of return_files (base64-encoded artifacts) and recommending env for secrets, reinforcing and supplementing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes code in an ephemeral, MicroVM-isolated sandbox, using a specific verb and resource. It conveys the core function and distinctive characteristics (isolation, ephemerality) without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical usage guidance such as using return_files to capture output artifacts and passing secrets via env instead of code strings. It implies appropriate contexts (e.g., untrusted code, one-off executions) though it doesn't explicitly contrast with alternatives, as none are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1scratchrun_execOnly one tool exists, so there is no possibility of confusion between tools. The tool's purpose is clearly described as sandboxed code execution, making it unambiguous.
The single tool name 'scratchrun_exec' follows a clear snake_case pattern with a descriptive prefix and verb. Consistency is trivially maintained when there is only one tool.
The server is focused entirely on one function: executing code in an ephemeral sandbox. One tool is exactly the right size for this narrow, well-defined purpose, and the parameter space covers execution, environment variables, and file output.
For the server's stated purpose (sandboxed code execution), the tool fully covers the lifecycle: execute code, pass environment variables, and retrieve output files. No obvious missing operations exist within the domain.
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Run Python code in a secure sandbox without local setup. Declare inline dependencies and execute s…
Execute code in 8 languages (Python, JS, TS, Go, Java, C++, C, Bash) in gVisor sandboxes.
Pay-per-call cybersecurity for AI agents: vuln scans, threat intel, compliance, code security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ar-blues/scratchrun-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
