Tailscale Compute

Tailscale Compute MCP

Run builds, tests, and benchmarks on your own remote compute node from an MCP coding agent.

The coding agent edits files on your local computer. This MCP server copies the project through rsync and runs a command through SSH only when the agent calls compute_run.

This is an independent project. It is not an official Tailscale product and is not endorsed by Tailscale Inc. Tailscale is a trademark of Tailscale Inc.

Release status

This package is a beta.

• The full path has run on a Mac laptop and an Apple M4 Mac mini.
• The server includes Linux probes and NVIDIA inventory support.
• Linux parsing has automated coverage.
• This release has not run on a real NVIDIA DGX Spark. Do not treat the Linux or NVIDIA result as DGX Spark validation yet.

How it works

MCP coding agent

| | local stdio v Tailscale Compute MCP | | rsync and SSH through the user's tailnet v Mac or Linux compute node

The package runs on the local computer. No MCP service runs on the remote node. The project author does not receive your code, credentials, command output, or Tailscale traffic.

Security warning

compute_run can run any non-interactive command with the permissions of the remote SSH user. Treat it as remote code execution.

• Use a dedicated non-root account on the remote node.
• compute_status reports the remote user id and warns when the SSH user is root. Run compute through a non-root user so a compromised build cannot control the whole node.
• Command starts, artifact fetches, and successful workspace deletions are recorded in a local audit log. The log never contains environment values, standard input, or credentials.
• Do not auto-approve command, fetch, cancel, or deletion tools.
• Do not put passwords, SSH private keys, or Tailscale auth keys in MCP configuration.
• Use an SSH agent or Tailscale SSH.
• Limit access with Tailscale policy rules.
• Review SECURITY.md before use.

Requirements

Local computer

• Node.js 20 or later.
• Tailscale connected to the same tailnet as the remote node.
• OpenSSH client.
• rsync with --include and --exclude support.
• An MCP host that supports local stdio servers.

macOS and Linux are the supported local systems for this beta.

Remote node

• Darwin or Linux.
• Tailscale connected.
• SSH server.
• rsync available on PATH.
• A known SSH host key.
• The toolchain required by the project.

The MCP package does not need Node.js on the remote node unless the remote workload uses Node.js.

Set up a Mac mini

1. Install and connect Tailscale on both Macs.
2. On the Mac mini, open System Settings, select General, select Sharing, and turn on Remote Login.
3. Add the local public key to the remote account:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@mac-mini.example.ts.net

1. Verify the host key and non-interactive access:

ssh user@mac-mini.example.ts.net /usr/bin/true

1. Check the remote tools:

ssh user@mac-mini.example.ts.net '/bin/zsh -lc "rsync --version"'

A sleeping or powered-off Mac might not accept a Tailscale connection. Configure macOS network wake when required. This MCP server does not send wake packets.

Set up a Linux node

Install and connect Tailscale by using the official Tailscale instructions for your Linux distribution. Then install an SSH server and rsync.

For Ubuntu or Debian:

sudo apt-get update

sudo apt-get install --yes openssh-server rsync sudo systemctl enable --now ssh

Use a standard SSH key:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@compute-node.example.ts.net

ssh user@compute-node.example.ts.net /usr/bin/true

You can use Tailscale SSH on supported Linux nodes instead of distributing SSH keys. Your Tailscale policy must permit both the network connection and SSH connection.

Install in an MCP host

Pin the package version. Do not use an unpinned package for agent command execution.

Oh My Pi (OMP)

Run the safe setup command for the default OMP profile:

npx -y @dylantirandaz/tailscale-compute-mcp@0.1.0-beta.5 \

setup omp \ --host user@compute-node.example.ts.net

The command prints the MCP configuration path and the fleet skill path. It runs the real SSH connection check before it writes a file. It then adds tailscale-compute to ~/.omp/agent/mcp.json and installs the managed tailscale-compute-fleet skill in ~/.omp/agent/skills/. It preserves other servers, pins this package version, and uses atomic file replacement.

The command does not write a file when the connection check fails. It refuses malformed JSON, symbolic links, a server name with different settings, and an unmanaged skill with the same name.

For a named profile, manually merge the server entry into ~/.omp/profiles/ /agent/mcp.json and install the skill in that profile's skills/tailscale-compute-fleet/ directory. Keep all existing server entries:

{

"mcpServers": { "tailscale-compute": { "type": "stdio", "command": "npx", "args": [ "-y", "@dylantirandaz/tailscale-compute-mcp@0.1.0-beta.5" ], "env": { "TAILSCALE_COMPUTE_HOST": "user@compute-node.example.ts.net" } } } }

Replace the example host with the SSH user and the Tailscale IP address or full MagicDNS name of your compute node.

Start a new OMP session after setup. OMP then loads the server and advertises the fleet skill to the agent automatically. In an existing session, /mcp reload loads the server, but the new skill becomes available in the next session. Test the server after reload or restart:

/mcp test tailscale-compute

Print a pinned configuration for Claude Code, Cursor, Codex, or OpenCode:

npx -y @dylantirandaz/tailscale-compute-mcp@0.1.0-beta.5 \

setup print --client \ --host user@compute-node.example.ts.net

The Claude output is a user-scoped command. The Cursor and OpenCode outputs are JSON. The Codex output is TOML for ~/.codex/config.toml. Merge JSON or TOML output with an existing client configuration instead of replacing unrelated entries.

VS Code

Create .vscode/mcp.json:

{

"servers": { "tailscale-compute": { "type": "stdio", "command": "npx", "args": [ "-y", "@dylantirandaz/tailscale-compute-mcp@0.1.0-beta.5" ], "env": { "TAILSCALE_COMPUTE_HOST": "user@compute-node.example.ts.net" } } } }

Cursor

Create .cursor/mcp.json:

{

"mcpServers": { "tailscale-compute": { "command": "npx", "args": [ "-y", "@dylantirandaz/tailscale-compute-mcp@0.1.0-beta.5" ], "env": { "TAILSCALE_COMPUTE_HOST": "user@compute-node.example.ts.net" } } } }

Claude Code

claude mcp add --scope user \

--env TAILSCALE_COMPUTE_HOST=user@compute-node.example.ts.net \ --transport stdio tailscale-compute \ -- npx -y @dylantirandaz/tailscale-compute-mcp@0.1.0-beta.5

Check the connection

Run the package outside the MCP host first:

TAILSCALE_COMPUTE_HOST=user@compute-node.example.ts.net \

npx -y @dylantirandaz/tailscale-compute-mcp@0.1.0-beta.5 --check

A successful check returns kind: "ready". It also reports:

• Operating system.
• CPU architecture and model.
• Logical processor count.
• Memory.
• Selected remote shell.
• rsync version.
• NVIDIA GPU inventory when nvidia-smi is available.
• Live uptime, load averages, available memory, storage capacity, active durable job count, and NVIDIA memory and utilization.

MCP tools

compute_status

Checks SSH access and reports the remote platform, hardware, and live health.

Installed GPU memory stays in hardware.acceleratorInventory. Current GPU memory use, available memory, and utilization stay in health.acceleratorUsage.

compute_doctor

Runs the explicit pytorch profile with one selected Python program on one required logical CUDA device:

{

"profile": "pytorch", "pythonProgram": "/opt/project/.venv/bin/python", "requiredDevice": "cuda:0", "minimumAvailableMemoryBytes": 24000000000 }

The selected Python program must contain PyTorch with CUDA support. The remote node must also provide nvidia-smi. The profile reports the NVIDIA driver, the PyTorch CUDA runtime, optional nvcc compiler, cuDNN, compute capability, available memory, dtype, and relevant backend flags. It runs a known torch.float32 linear operation and verifies its result. It also verifies that the model, input, intermediate value, and output stay on the required device. A missing requirement returns check_failed; the profile never selects a different GPU or falls back to the CPU.

The doctor proves only its small operation. Run the real workload and check its outputs before you claim application support.

compute_workspace_status

Reports the managed remote path, disk usage, last successful sync, last run request, and active durable job IDs for one local workspace.

compute_workspace_delete

Deletes only the managed remote directory that maps to one local workspace. It refuses deletion while a durable job is active. A repeated delete succeeds and reports existed: false.

compute_run

Copies the local workspace and runs one non-interactive remote command.

Example:

{

"program": "npm", "arguments": ["test"], "syncMode": "incremental", "timeoutSeconds": 900 }

For shell syntax, call a supported remote shell explicitly:

{

"program": "/bin/bash", "arguments": ["-lc", "npm ci && npm test"], "syncMode": "clean", "timeoutSeconds": 1800 }

compute_run returns the remote exit code, standard output, standard error, sync time, and command time. Output is limited to protect the MCP connection. When output is too large, the result keeps its start and end and reports the omitted byte count.

Hardware requirements

compute_run and compute_job_start accept an optional requirements object. The server checks these requirements against the remote hardware before it starts the workload. It returns kind: "requirements_not_met" and does not sync or start the command when a requirement fails.

{

"program": "python", "arguments": ["train.py"], "requirements": { "platform": "linux", "architecture": "x86_64", "minimumMemoryBytes": 34359738368, "nvidia": { "minimumDeviceCount": 1, "minimumMemoryBytesPerDevice": 24000000000 } } }

The server does not select a device and does not fall back to the CPU. The workload must select and verify its required accelerator.

Durable jobs

compute_job_start syncs the workspace and starts a detached command. It returns a job ID after the remote launcher starts. The command continues when the MCP client disconnects.

{

"program": "python", "arguments": ["train.py"], "syncMode": "incremental", "timeoutSeconds": 43200, "idempotencyKey": "training-run-2026-08-14", "label": "baseline", "artifactPaths": ["checkpoints/final.pt", "metrics/results.json"] }

• compute_job_status returns starting, running, completed, failed, cancelled, or lost.
• compute_job_logs reads stdout or stderr from an exact byte offset. Use nextOffsetBytes in the next call. endOfStream becomes true after the job reaches a terminal state and the returned offset reaches the file size.
• compute_job_cancel stops the remote process group. A terminal job returns its existing terminal state.
• compute_job_list returns a filtered, paged list with job IDs, states, labels, programs, workspace paths, times, and terminal results.
• compute_job_delete deletes only a terminal job. It refuses active jobs and unsafe remote job directories.

Each terminal job state includes output byte counts and SHA-256 digests.

An idemp