Workstation MCP Servers

A workstation MCP server runs locally — on a user’s laptop, desktop, or an on-premises server — and connects to MCP Manager through an encrypted tunnel. The server is never exposed to the public internet: all traffic between MCP Manager and a workstation server flows through an end-to-end encrypted tunnel built on WireGuard. This lets a server that must run on a specific machine still sit behind the gateway, where every tool call is logged, inspected, and governed. Ready to set one up? The tutorial Connect a workstation MCP server walks the whole path, from creating the server to calling a local tool through a gateway, in about ten minutes. This page covers the concepts behind it.

​

Why use a workstation server

A workstation server is the right choice when:

• The server needs local access — tools like Playwright (browser automation), filesystem servers, or anything that interacts with a user’s machine need to run where that machine is.
• You’re working with on-premises resources — if a server must reach systems available only on your internal network, running it on a workstation inside that network is the simplest approach.
• You want governance for local servers — even though the server runs locally, all traffic still flows through the MCP Manager gateway, so you keep full logging, security guardrails, identity management, and access control.

The key benefit is visibility. Without a gateway, local MCP servers are invisible to your organization’s security and governance tooling. With workstation servers connected through MCP Manager, every tool call is logged, inspected, and subject to your policies.

​

How a workstation server connects

MCP Manager uses a lightweight tunnel agent to create a secure connection between the workstation and the gateway. A small container runs on the machine and establishes an encrypted tunnel to MCP Manager. The gateway routes requests through that tunnel; on the workstation, a local router validates each request with an access key before forwarding it to your MCP server. The tunnel handles NAT traversal automatically, so workstation servers work even behind firewalls or corporate networks with no special configuration in most environments. The exception is a corporate proxy or secure web gateway that intercepts outbound traffic — see When a network proxy blocks the connection. Because the connection is outbound from the workstation and end-to-end encrypted, the local server is never exposed to the public internet, and only requests carrying the correct access key reach it. Even though the connection is encrypted, MCP Manager can still see every request that flows through it. That’s deliberate: it’s how each call gets checked against your policies and written to the audit log before reaching your server. It’s what keeps a server on a laptop as governed as any other.

​

What you need to connect a workstation server

Before you run the generated command, the machine needs:

• Docker — the tunnel agent runs as a container on your machine.
• The local MCP server you want to connect, or the command that launches it.
• Outbound network access to MCP Manager’s tunnel endpoint. To bring up the tunnel, the agent dials outbound to headscale.mcpmanager.ai on TCP port 443. It opens no inbound ports, but this outbound connection must be allowed to leave the machine.

Validate the outbound access before you start, especially on a corporate network. Secure web gateways and TLS-inspection proxies — Zscaler, Netskope, Cisco Umbrella, and similar SSE/SASE tools — frequently intercept outbound traffic and break the tunnel’s handshake, leaving setup stuck. Confirm the machine can reach headscale.mcpmanager.ai on port 443 without TLS interception, or have it allowlisted. If setup stalls, see When a network proxy blocks the connection.

​

The setup experience: TUI and CLI

MCP Manager provides an in-product wizard that generates a single Docker command for you to run on the workstation. The command starts the tunnel agent and connects your local MCP server to MCP Manager. The TUI is your dashboard for setup and monitoring. It provides:

• Connection status — the progress of each step as the tunnel comes up and the workstation registers.
• Health monitoring — real-time health information and connection statistics.
• Logs — local workstation logs for troubleshooting.
• Port information — which ports are in use on the machine.
• Server controls — start, stop, or restart the workstation connection.

The container runs in the background with an automatic restart policy, so the workstation server stays connected even after reboots. Once the connection is established, the TUI keeps working silently in the background — you only need it for setup and monitoring.

​

When a network proxy blocks the connection

If the setup TUI stalls at “Tailscale daemon started” — the step stays yellow and never advances to “Authenticated on tailnet” — the tunnel agent can’t reach MCP Manager’s coordination server. The usual cause is a corporate secure web gateway or TLS-inspection proxy intercepting the outbound connection. The encrypted tunnel is built on WireGuard. To establish it, the agent opens an outbound connection to headscale.mcpmanager.ai on TCP 443. Products such as Zscaler Internet Access, Netskope, Cisco Umbrella, Cloudflare Gateway, Palo Alto Prisma Access, Forcepoint, Broadcom/Symantec Web Security Service, and Microsoft Entra Internet Access can block that connection or re-sign its certificate, which leaves the daemon waiting and the step stuck. To fix it:

• Allowlist the endpoint (recommended). Have your network or IT team permit outbound access to headscale.mcpmanager.ai on TCP 443 and exempt it from TLS/SSL inspection — an allow rule alone is not enough if the proxy still re-signs the certificate. Allowlist by hostname, not IP, since the underlying addresses can change.
• Temporarily disable the proxy on the machine to confirm it’s the cause, then add the allowlist entry for a lasting fix.

Once the endpoint is reachable, run the command again — the TUI advances past “Tailscale daemon started” and completes the remaining steps.

​

Governance and visibility

Routing local MCP traffic through the MCP Manager gateway is what makes workstation servers safe to use at an organization. The same logging, gateway rules, identity management, and access controls that apply to remote and managed servers apply here — so a server running on a laptop is no longer a blind spot. Every request is recorded and inspected, and a connection that drops is automatically retried by the tunnel agent.

​

Identities for workstation servers

Workstation servers use the same identity model as every other server type: an identity is Private by default or Global to share across your organization, and administrators can require per-user identities or share a single identity across a gateway. See the identities section of the overview for the full model.

​

Pros and cons

• Pros: direct access to the local environment (files, editors, hardware) with no intervening abstraction; never exposed to the public internet; full gateway governance, logging, and policy even though the server runs locally; works behind firewalls without special networking.
• Cons: the server still depends on the machine it runs on being available; large-scale rollouts benefit from configuration-management tooling to distribute the command.

​

Further reading

​

External sources