Workstation MCP Servers

Documentation Index

Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt

Use this file to discover all available pages before exploring further.

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.

​

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. 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.

​

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.

​

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