> ## 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.
# Connect a workstation MCP server
> A hands-on walkthrough for connecting an MCP server running on your own machine to MCP Manager: create a workstation server, configure a local instance, run the generated commands to start the encrypted tunnel, test the connection, and call a local tool through a governed gateway.
By the end of this tutorial you'll have an MCP server running on **your own machine** connected to **MCP Manager** through an encrypted tunnel — without exposing anything to the internet. The server sits behind a [gateway](/mcp-gateway-concepts/mcp-gateways) like any other, so every tool call against it is logged, inspected, and governed.
To keep things concrete, this tutorial connects one specific server: the official [filesystem MCP server](https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem), which gives an AI client access to a folder you choose. The whole path takes about ten minutes.
**Following along with your own server?** Everything here works the same regardless of what you connect. The proxy, the tunnel, and the gateway don't change. Only two things depend on your server, and each is flagged inline with **Your own server**:
1. The **command or URL** you enter in [Step 2](#step-2-configure-the-instance).
2. The **tool you call** in [Step 5](#step-5-call-a-tool-through-a-gateway).
Wherever you see that marker, swap in your own value; everywhere else, follow along as written.
This tutorial uses the capabilities **Deploy new workstation instances** and **Create and configure managed and workstation servers**. If the **Workstation** option isn't available when you add a server, your role lacks the capability or the feature isn't enabled for your workspace — ask a workspace administrator. See the [capabilities reference](/deployment/rbac-and-roles/capabilities).
## What you'll need
* An MCP Manager workspace you can sign in to.
* [Docker](https://docs.docker.com/get-started/) running on your machine — the tunnel agent runs as a container.
* [Node.js](https://nodejs.org/) (for `npx`) — used to launch the example server. If you're connecting a local server that already speaks HTTP, you can skip this.
* A folder on your machine you're happy to share with an AI client.
* Outbound access to `headscale.mcpmanager.ai` on TCP 443 — the tunnel connects out to it. On a corporate network, confirm a secure web gateway or TLS-inspection proxy (Zscaler, Netskope, and similar) isn't blocking it. See [When a network proxy blocks the connection](/mcp-gateway-concepts/mcp-servers/workstation#when-a-network-proxy-blocks-the-connection) if setup stalls.
* About ten minutes.
## Step 1: Create the workstation server
Go to [MCP Servers](https://app.mcpmanager.ai/settings/servers) and click **Add**. The **Add an MCP server** dialog opens with three server types.
Select **Workstation** — "The MCP servers run on personal computers."
In **Server Name**, enter `My Workstation`, then click **Save MCP server**. MCP Manager creates the server and takes you to its **Server instances** tab.
A workstation server is a container for **instances** — each instance is one local MCP server on one machine. You've created the container; next you'll add the instance that actually runs on your machine.
## Step 2: Configure the instance
This is the one step where your own server differs from the tutorial's example. It's where you tell MCP Manager what to connect to; everything after it is identical no matter what you connect.
On the **Server instances** tab, click **Add server instance**. The **Connect a workstation MCP server** dialog opens.
In **Instance name**, enter `Local filesystem` — or any name that helps you recognize this server later.
The wizard offers two paths, and which one fits depends on your server:
* **Launch new (STDIO)** — for a server that starts from a command (an `npx`/`uvx` package, a script, a binary). MCP Manager wraps it and exposes it locally for you.
* **Connect to existing (Streamable HTTP)** — for a server that's **already running** on your machine and listening at a URL.
The filesystem server starts from a command, so this tutorial uses **Launch new (STDIO)**.
For the filesystem server, set **Command** to:
```text Command theme={null}
npx -y @modelcontextprotocol/server-filesystem@latest
```
Leave **Port** at `8000`. Under **Command arguments**, add one argument — the absolute path of the folder to share, for example `/Users/you/Documents/notes`. Click **Next**.
**Your own server:** this is where it goes.
* If it **starts from a command** (STDIO), replace the command, port, and arguments above with your server's own.
* If it's **already running at a URL**, choose **Connect to existing (Streamable HTTP)** instead. You'll see a single **Destination URL** field — enter the URL your server listens on (for example `http://localhost:3000/mcp`) and any **Custom headers** it needs. Then skip the first command in [Step 3](#step-3-run-the-generated-commands); the rest is the same.
## Step 3: Run the generated commands
The **Deploy workstation proxy** screen shows the commands to run on your machine, each with a **Copy command** button. Keep this dialog open — you'll come back to it to test the connection.
Copy the first command, **Start your MCP server (StreamableHTTP)**, and run it in a terminal. MCP Manager builds it from what you entered in Step 2, so yours carries your own command and arguments. For the filesystem server it looks like this:
```bash terminal theme={null}
npx -y supergateway --stdio "npx -y @modelcontextprotocol/server-filesystem@latest /Users/you/Documents/notes" --port 8000 --outputTransport streamableHttp --stateful
```
Leave it running. This terminal is now your MCP server.
**Why this command uses `supergateway`.** The filesystem server, like many MCP servers, speaks **STDIO**. That means it talks over its own input and output streams, the way a command-line program does, instead of over the network. The workstation proxy connects to your server over **HTTP**, so it needs a network address to reach.
That's the gap [`supergateway`](https://github.com/supercorp-ai/supergateway) fills. It launches your STDIO server, keeps it running, and republishes it as a local HTTP endpoint on the port you chose, which gives the proxy something to connect to. MCP Manager adds it to the command for you.
A server that already speaks HTTP doesn't need this bridge, which is why the **Connect to existing** path in Step 2 skips this command.
Copy the second command, **Start MCPM's workstation proxy**, and run it in a second terminal. It launches the tunnel agent that connects your machine to MCP Manager. It looks like this, with a registration token unique to your instance:
```bash terminal theme={null}
docker run --rm -it --net=host -v "/var/run/docker.sock:/var/run/docker.sock" -e MCPM_REGISTRATION_TOKEN="" mcpmanager/cli:latest workstation
```
The command opens an interactive dashboard (TUI) in your terminal showing each connection step as the tunnel is established and the workstation registers with MCP Manager. Wait for the steps to complete.
If the TUI **stalls at "Tailscale daemon started"** and never advances, a corporate proxy or secure web gateway (Zscaler, Netskope, and similar) is likely blocking the tunnel's outbound connection to `headscale.mcpmanager.ai` on TCP 443. See [When a network proxy blocks the connection](/mcp-gateway-concepts/mcp-servers/workstation#when-a-network-proxy-blocks-the-connection).
The connection is **outbound** from your machine, so nothing inbound is opened. On most networks no firewall changes are needed, but a corporate secure web gateway or TLS-inspection proxy may need to allow outbound access to `headscale.mcpmanager.ai` on TCP 443 — see [When a network proxy blocks the connection](/mcp-gateway-concepts/mcp-servers/workstation#when-a-network-proxy-blocks-the-connection). Traffic between your machine and MCP Manager is encrypted with WireGuard. MCP Manager reads each call to apply your policies and log it, then forwards it to your server. That visibility is the point. [Workstation MCP Servers](/mcp-gateway-concepts/mcp-servers/workstation) covers how the tunnel works.
## Step 4: Test the connection
Back in the browser, click **Test connection**. MCP Manager reaches your server through the tunnel, discovers its tools, and takes you to the instance's **Features** page. For the filesystem server you'll see `read_file`, `list_directory`, `search_files`, and the rest; for your own server, you'll see whatever tools it provides.
If you see **"Connection failed. Make sure the workstation proxy is running and try again,"** check that both terminal commands from Step 3 are still running, then click **Test connection** again.
Your local server is connected. From here on it behaves like any other server in MCP Manager — same gateways, same rules, same logs.
## Step 5: Call a tool through a gateway
A server isn't reachable until a gateway exposes it — same as every other server type.
Go to [Gateways](https://app.mcpmanager.ai/settings/gateways) and open a gateway you use (or create one — see [your first governed tool call](/tutorials/first-tool-call) for the full walkthrough). On its **Servers** tab, click **Assign a server** and select **My Workstation**.
In an AI client connected to that gateway, ask something that reaches for the filesystem server:
```text theme={null}
List the files in my notes folder.
```
The request travels from your client through the MCP Manager gateway, down the encrypted tunnel, to the server on your machine — and the answer comes back the same way.
**Your own server:** ask for something one of *its* tools does instead. The path is identical. Only the prompt and the tool that answers it change.
Go to [Logs](https://app.mcpmanager.ai/settings/logging/logs) and look for the newest `tools/call` entry. It shows who made the call, through which gateway, on your workstation server.
You connected a server running on your own laptop to MCP Manager, called one of its tools from an AI client, and found the call in your audit log — with nothing exposed to the internet, no VPN, and no firewall changes. A local server is no longer a governance blind spot.
## What's next
* Understand how the tunnel, local router, and access key work in [Workstation MCP Servers](/mcp-gateway-concepts/mcp-servers/workstation).
* Add a guardrail to the gateway in [Add your first gateway rule](/tutorials/first-gateway-rule).
* Trim which tools the gateway exposes in [Build a team gateway](/tutorials/team-gateway).
## Further reading
The concepts behind what you just built — the tunnel, the local router, and the governance model.
The end-to-end quickstart: add a server, create a gateway, and trace a call.
The same generated-command experience for servers in your own data center.
The capabilities that gate workstation deployment.