Exposing an MCP server to the internet — tunneling guide for Claude Desktop and Cursor

MCP servers usually run on your localhost — which means hosted

Claude, Cursor on another machine, or a teammate can't reach them.

The fix is a tunnel, but the details matter: which URL survives

restarts, how the config files actually look, and how to avoid

handing your AI tooling a credential it can burn down your account

with.

 This is the full walkthrough.

 ## Why your MCP server is unreachable

 The Model Context Protocol server you just wrote listens on a

local port. That works beautifully when the client is on the same

machine. The moment the client is hosted Claude, a colleague's

Cursor, or anything off-box, localhost becomes a wall: NATs,

firewalls, and the simple fact that localhost:8080

means

something different on every machine.

 A tunnel solves it by running an agent on your machine that

holds a persistent outbound connection to a public edge. Traffic

to your public URL flows down that connection to your local port.

Step 1: Pick a URL that survives restarts

 This is the detail most guides skip, and the one that bites

first. MCP client configs hardcode the server URL. If your tunnel

hands you a new random address on every restart, your config

breaks silently every morning.

 Use a named subdomain so the address is permanent:
``` bash
 mytunnel http 8080 --subdomain my-mcp

That URL is yours across restarts and reboots — paste it into

configs once and stop thinking about it.

   Step 2: Wire up Claude Desktop

   Edit claude_desktop_config.json:

   ``` json
     {
       "mcpServers": {
         "my-server": {
           "url": "https://my-mcp.21tunnel.com/sse"
         }
       }
     }

Restart Claude Desktop and the hosted client now talks to the MCP

server on your machine, through the tunnel.

Step 3: Wire up Cursor

Same shape in .cursor/mcp.json:

     {
       "mcpServers": {
         "my-server": {
           "url": "https://my-mcp.21tunnel.com/sse"
         }
       }
     }

Now Cursor on any machine — yours, a teammate's, a CI box — can

reach the same server.

Step 4: Don't hand the agent your master token

If an AI agent is the one opening tunnels, here. The default

is exporting your tunnel service's account token into the agent's

environment. That token can typically open unlimited tunnels,

never expires, and shows up in transcripts and logs.

The safer pattern: a master key that cannot open tunnels itself,

which the agent uses to mint its own scoped, short-lived child key

per project:

     eval "$(mytunnel eval mint --project mcp --ttl 4h --output-env)"
     mytunnel http 8080 --subdomain my-mcp

The agent works autonomously, the credential dies on schedule, and

one click cascade-revokes everything it ever created.

Step 5: Gate it if it matters

A public MCP endpoint is a public door. For anything beyond a

quick test, enable edge auth so the URL only responds to signed-in

teammates or an allowlisted domain. One toggle in the dashboard,

no code changes.

That's the whole setup: permanent URL, two config files, scoped

credentials, access control. The full guide with more config

variants: exposing an MCP server to the internet

source & further reading

dev.to — original article 'PleaseFix': When Your AI Browser Trusts a Web Page More Than It Trusts You MCP attack classes: a reference The bug that passes every test and does nothing. I let an AI write more than I read, and the tests that would have caught all of it.