Tailscale Compute MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TAILSCALE_COMPUTE_HOST | Yes | SSH user and direct Tailscale IP address or full MagicDNS name. | |
| TAILSCALE_COMPUTE_LOCAL_ROOT | No | Absolute local project path. Defaults to MCP process directory. | MCP process directory |
| TAILSCALE_COMPUTE_REMOTE_ROOT | No | Managed remote workspace root. | .cache/tailscale-compute-mcp |
| TAILSCALE_COMPUTE_REMOTE_SHELL | No | Remote shell: auto, /bin/sh, /bin/bash, or /bin/zsh. | auto |
| TAILSCALE_COMPUTE_CONNECT_TIMEOUT_SECONDS | No | SSH connection timeout from 1 through 60 seconds. | 10 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| compute_statusA | Check the configured Tailscale compute node and report its operating system, hardware, remote shell, and accelerator inventory. Use this before the first remote run or after a connection failure. |
| compute_runA | Sync the local project and run one non-interactive command on the configured Tailscale compute node. Use it for builds, tests, benchmarks, and other costly work. Keep file edits local. The command has the full permissions of the remote SSH user. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
compute_status and compute_run are clearly distinct: one inspects the remote node's configuration and health, while the other executes a command. There is no overlap or ambiguity between the two tools.
Both tools follow the same compute_ prefix with a concise action suffix (status, run), creating a consistent and predictable naming pattern.
With only two tools, the server is under the typical 3-15 range, but the scope is intentionally narrow—checking status and running commands on a configured remote node. Each tool is essential and earns its place.
The server covers the core workflow: verify connectivity/state with compute_status and perform remote work with compute_run, which includes automatic project syncing. No obvious gaps exist for its stated purpose.