@cinch-codes/mcp

MCP server for Cinch. Gives your AI assistant a real sandbox to run code in.

Without it, an assistant writes code and you run it yourself. With it, the assistant runs the code and reads the actual output — inside a gVisor-isolated container on Cinch's infrastructure, with no access to your machine, filesystem, or local network.

Pay per execution. No subscription floor.

Setup

Get an API key at cinch.codes, then add the server to your MCP client.

Claude Desktop — claude_desktop_config.json:

{
  "mcpServers": {
    "cinch": {
      "command": "npx",
      "args": ["-y", "@cinch-codes/mcp"],
      "env": {
        "CINCH_API_KEY": "cinch_live_..."
      }
    }
  }
}

Claude Desktop on Windows — same file, but Windows can't spawn npx directly, so wrap it with cmd /c:

{
  "mcpServers": {
    "cinch": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@cinch-codes/mcp"],
      "env": {
        "CINCH_API_KEY": "cinch_live_..."
      }
    }
  }
}

Claude Code (macOS/Linux):

claude mcp add --scope user cinch -e CINCH_API_KEY=cinch_live_... -- npx -y @cinch-codes/mcp

Claude Code (Windows):

claude mcp add --scope user cinch -e CINCH_API_KEY=cinch_live_... -- cmd /c npx -y @cinch-codes/mcp

Cursor — .cursor/mcp.json, same shape as the Claude Desktop config above.

Restart the client. That's it — no install step, npx fetches it on first run.

Related MCP server: Capsule server

What it exposes

execute_code

Runs a self-contained Python or JavaScript program and returns stdout, stderr, exit code, and duration.

Each call gets a clean sandbox. State does not persist between calls, so every snippet needs to stand on its own.

The sandbox environment

Deliberately minimal. Worth knowing before you wonder why an import failed:

The tool description tells the model all of this up front, so it writes stdlib-only code instead of reaching for numpy and failing on the first call.

Configuration

Troubleshooting

Windows: "Failed to connect" in claude mcp list — you're missing the cmd /c wrapper. Windows resolves npx to a batch script that can't be spawned directly; re-add the server using the Windows command above.

Windows: npm error ENOENT ... AppData\Roaming\npm — some Node installs never create npm's global folder, and npx refuses to run without it. Create it once and retry:

mkdir %APPDATA%\npm

Server exits immediately with "CINCH_API_KEY is not set" — the env var didn't reach the server. In Claude Code, put -e CINCH_API_KEY=... before the server name in claude mcp add. In config files, check the env block is inside the cinch entry.

Debugging any connection failure — run the server directly to see the real error instead of a generic status:

CINCH_API_KEY=cinch_live_... npx -y @cinch-codes/mcp   # macOS/Linux

set CINCH_API_KEY=cinch_live_... && cmd /c npx -y @cinch-codes/mcp   # Windows

Correct behavior is cinch-mcp ... ready followed by silence — an MCP server waits for a client. Anything else printed is the actual failure.

Why sandboxed execution

Code written by a model is untrusted code — nothing reviewed it before it ran. Executing it directly on your machine means handing it your filesystem, your network, and your credentials. Cinch runs it somewhere else entirely, in a disposable container with kernel-level isolation, and sends back only the output.

Notes

• Requires Node 18 or newer.

• Output is capped at 20,000 characters per stream to protect your context window; anything beyond that is truncated with a marker.

• Runs that time out or exit non-zero are returned as tool errors, so the assistant knows the code failed and can correct it.

• Out-of-credit responses are surfaced clearly and instruct the assistant not to retry, so a drained balance does not turn into a retry loop.

Links

• cinch.codes

• JS/TS SDK: @cinch-codes/pangolin

• Python SDK: pangolin-sdk

MIT