Skip to main content
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 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, 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.
  2. The tool you call in Step 5.
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.

​
What you’ll need

  • An MCP Manager workspace you can sign in to.
  • Docker running on your machine — the tunnel agent runs as a container.
  • Node.js (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 if setup stalls.
  • About ten minutes.

​
Step 1: Create the workstation server

1

Open the add-server flow

Go to MCP Servers and click Add. The Add an MCP server dialog opens with three server types.
2

Choose Workstation

Select Workstation — “The MCP servers run on personal computers.”
3

Name it and save

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

Open the instance wizard

On the Server instances tab, click Add server instance. The Connect a workstation MCP server dialog opens.
2

Name the instance

In Instance name, enter Local filesystem — or any name that helps you recognize this server later.
3

Choose how your server runs

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

Enter the command and port

For the filesystem server, set Command to:
Command
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; 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.
1

Start your MCP server

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:
terminal
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 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.
2

Start the workstation proxy

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:
terminal
docker run --rm -it --net=host -v "/var/run/docker.sock:/var/run/docker.sock" -e MCPM_REGISTRATION_TOKEN="<your-registration-token>" mcpmanager/cli:latest workstation
3

Watch the tunnel come up

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

Assign the server to a gateway

Go to Gateways and open a gateway you use (or create one — see your first governed tool call for the full walkthrough). On its Servers tab, click Assign a server and select My Workstation.
2

Ask your AI client to use it

In an AI client connected to that gateway, ask something that reaches for the filesystem server:
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.
3

Find the call in your logs

Go to 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

​
Further reading

Workstation MCP Servers

The concepts behind what you just built — the tunnel, the local router, and the governance model.

Your first governed tool call

The end-to-end quickstart: add a server, create a gateway, and trace a call.

Managed MCP Servers

The same generated-command experience for servers in your own data center.

Capabilities reference

The capabilities that gate workstation deployment.