LABSCO SUMMARY

Lets a model check its own code by running it, instead of asserting that it works.

Both tools execute inside a sandbox — the JavaScript side under permissions you grant explicitly, the Python side in WebAssembly — so the blast radius is whatever you opened, not your shell. Install-on-demand is what makes it useful for verification rather than just execution: an agent can pull an unfamiliar package and find out whether it does what its docs claim.

What it is

A server with two execution tools — one runs JavaScript or TypeScript, the other runs Python — each inside its own sandbox, and each able to pull in packages by name at the moment they are imported.

What you get

JavaScript and TypeScript executed in a permissioned runtime, with network access closed until you grant it
Python executed inside a WebAssembly environment rather than against a system interpreter
Packages imported by name and fetched on demand from npm, JSR or PyPI — nothing installed on your machine first
A mapping option for Python packages whose import name differs from the name they are published under
An explicitly configured window onto one host directory, for code that has to touch real files
Either language switched off, so you can expose only the runtime you want an agent to have
A quiet mode that keeps package-install chatter out of the tool output

Requirements

A JavaScript runtime on the machine. The documented setups either call a sandboxing runtime directly or have the Node package manager fetch it on demand, so there is nothing to install ahead of time. Filesystem access is closed until you name a host directory, and outbound network access on the JavaScript side is closed until you grant that permission.

Setup effort

Add the configuration to your client

See installation options

USE CASES

01

Checking whether a package really does what its README claims

Import it by name and run a few lines against it. It is fetched for that run, so your machine stays clean either way.

02

Making a model verify its own logic

Have it execute the function it just wrote and read the actual output before you accept the answer.

03

Running a data calculation instead of estimating it

Pull a data library on demand inside the Python sandbox and compute the number rather than reasoning about it.

04

Letting sandboxed code work on files you actually have

Point the sandbox at a single host directory so a script can read and write there, and nowhere else.

05

Giving an agent one language and not the other

Enable only the runtime you want exposed, so a Python-only setup cannot reach the JavaScript sandbox.

BEFORE YOU INSTALL

What to know first

Requires

Deno, or Node.js with npx (the npx route downloads Deno on demand)

Where it runs

Both documented setups run the server on your machine.

INSTALLATION

Connect your client

MCP Clients

Any MCP client — Deno

ANY MCP CLIENT — DENO · JSON

{
  "mcpServers": {
    "code-runner": {
      "command": "deno",
      "args": [
        "run",
        "--allow-all",
        "jsr:@mcpc/code-runner-mcp/bin"
      ],
      "env": {
        "DENO_PERMISSION_ARGS": "--allow-net",
        "NODEFS_ROOT": "/tmp",
        "NODEFS_MOUNT_POINT": "/tmp"
      },
      "transportType": "stdio"
    }
  }
}

Any MCP client — npx

ANY MCP CLIENT — NPX · JSON

{
  "mcpServers": {
    "code-runner": {
      "command": "npx",
      "args": [
        "-y",
        "deno",
        "run",
        "--allow-all",
        "npm:@mcpc-tech/code-runner-mcp@latest"
      ],
      "env": {
        "DENO_PERMISSION_ARGS": "--allow-net",
        "NODEFS_ROOT": "/tmp",
        "NODEFS_MOUNT_POINT": "/tmp"
      },
      "transportType": "stdio"
    }
  }
}

Code Runner MCP