Expose Your MCP Gateway to the Internet Without Port Forwarding
Getting a remote AI agent, a teammate, or a cloud hosted Claude instance to reach your MCP tools used to mean juggling a separate gateway install, router config, and TLS. Localtonet collapses all of that into one client. McpNet Gateway runs automatically the moment you install Localtonet, already secured, with the admin token set through Localtonet's own settings. Point the built in MCP Gateway tunnel at it and you have a public HTTPS endpoint in a couple of minutes.
Why Self Hosted MCP Gateways Are Hard to Reach
McpNet Gateway sits between your AI agents and every upstream MCP server you run, exposing all of them through one authenticated endpoint at /mcp. That's exactly what you want when Claude, Cursor, or a custom agent needs a single place to discover tools. The problem shows up the moment that agent lives somewhere other than your machine. By default the gateway binds locally and listens on port 5050. Nothing outside your LAN can see it.
Port forwarding used to be the answer, but most home and office connections now sit behind CGNAT, so there's no public IP to forward to in the first place. Even where a static IP exists, TLS still needs to be handled by something in front of the gateway.
A tunnel gives McpNet Gateway a public HTTPS address without opening an inbound port on your router, and without you having to run a separate reverse proxy for TLS.
The Simple Version: It's Already Built In, Already Secured
There is no separate McpNet Gateway install to worry about. Once you install the Localtonet client, McpNet Gateway runs automatically alongside it on port 5050, and it never starts in the unauthenticated Dev mode. The admin token is set directly through Localtonet's own settings, there's no config file to edit and nothing extra to lock down before you tunnel. The fastest way to get started is to go straight to localtonet.com/tunnel/mcpgateway. That single page lets you download the latest Localtonet client and, once it's installed and you're logged in, shows the exact same MCP Gateway creation screen you'll use to launch your tunnel.
/mcp and /dashboard routes without any manual host or port entry.
localto.net subdomain is served over TLS automatically, so there's no reverse proxy to set up yourself.
localto.net for your own domain through the Domain dropdown if you've added one via DNS Manager.
How to Expose McpNet Gateway with Localtonet: Step by Step
Get the Localtonet client
Go to localtonet.com/tunnel/mcpgateway and download the latest Localtonet client for your platform, Windows, Linux, macOS, or Docker. McpNet Gateway comes bundled with it, there is nothing extra to install. If you don't have a Localtonet account yet, sign up first, no credit card required.
Install the client and log in with your token
Install the client and open it. Log in using the token from localtonet.com/usertoken.
Fill in four fields and hit Create
Back on the MCP Gateway page, you'll see the same screen as the dashboard's My Tunnels → MCP Gateway section. Four fields, no host or port to type by hand:
Process Type: Random SubDomain is fine for testing. If your plan supports a fixed subdomain, use it instead, since every AI client config hardcodes your MCP server URL and a changing subdomain means updating that config everywhere.
Auth Token: Default Token works for a single machine. If you're tunneling from more than one server, generate and select the token tied to that specific client from localtonet.com/usertoken.
Server: pick the region closest to wherever your AI agents actually run, not where you personally sit. Available regions include UK London and TR.
Domain: leave this as localto.net for a quick setup, or select a custom domain you've already added through DNS Manager.
Click Create, then click the green Start button next to your new tunnel. Your gateway is now live at a URL like https://brlgqocwsk.localto.net, or your chosen fixed subdomain.
Connect your MCP client to the public URL
Point every agent config at your tunnel URL:
https://your-gateway.localto.net/mcp
Authorization: Bearer YOUR_CLIENT_TOKENIf any upstream server runs through npx, its package downloads on first connect, which can take 60 to 120 seconds. McpNet uses a 120 second per server timeout and the tool list fills in on the next background refresh about 60 seconds later. A slow first call through the tunnel is McpNet warming up, not a tunnel problem. Give it one retry before troubleshooting.
Running McpNet Gateway Standalone (NuGet or GitHub)
Everything above assumes you're using the McpNet Gateway that ships inside Localtonet, which is the fastest path and needs no configuration. If instead you'd rather run McpNet Gateway on its own, outside of Localtonet, by installing it from NuGet or building it from the GitHub repository, that standalone build does start in Dev mode by default, with no authentication. In that case you're responsible for switching it to Enterprise mode and setting your own admin token before exposing it:
McpGateway__Mode=Enterprise
McpGateway__AdminToken=your-strong-admin-tokenYou can still tunnel a standalone install with Localtonet's MCP Gateway tunnel type, it just points at whatever port your standalone instance is listening on instead of the bundled one.
Tips for Running MCP Gateway Behind a Tunnel
AllowedServerIds and AllowedGroupIds fields let you hand a remote agent a token that only sees the tools it needs. Leaving both empty grants access to everything, so set this up before the tunnel goes live.
GET /api/audit regularly. It logs every tool call with client, duration, and success, making it the fastest way to notice a leaked token being misused.
mcp-data/dp-keys/. Losing that folder makes every encrypted secret unrecoverable, tunnel or not.
-32029 when exceeded. Set a sane global RateLimitPerMinute so a misbehaving agent can't flood your upstream servers through the public URL.
Localtonet vs Alternatives for Exposing MCP Gateways
| Feature | ngrok | Cloudflare Tunnel | Localtonet |
|---|---|---|---|
| Gateway bundled with the client | ✘ | ✘ | ✔ |
| Secured by default, no Dev mode | n/a | n/a | ✔ |
| Dedicated MCP Gateway tunnel type | ✘ | ✘ | ✔ |
| Free HTTPS subdomain | ✔ | ✔ | ✔ |
| Fixed subdomain on free plan | ✘ | ✔ | ✔ |
| Requires a registered domain | ✘ | ✔ | ✘ |
| Multi region server selection | ~ | ✔ | ✔ |
| Setup time for a gateway tunnel | ~5 min | ~15 min | ~1 min |
| Price | $0 to $10+/mo | $0 | $0 to $2/tunnel/mo |
Frequently Asked Questions
Do I need to install McpNet Gateway separately from GitHub or NuGet?
No, not if you're using Localtonet. McpNet Gateway is bundled with the Localtonet client and starts automatically once you install it. GitHub and NuGet installs exist for people who want to run McpNet Gateway completely standalone, outside of Localtonet.
Do I need to enter a host or port when creating the MCP Gateway tunnel?
No. The MCP Gateway tunnel type only asks for Process Type, Auth Token, Server, and Domain. It's already wired to forward to the bundled gateway, unlike a generic HTTP tunnel where you manually specify host and port.
Do I need to switch anything from Dev mode to Enterprise mode before tunneling?
Not with the bundled Localtonet version, it never runs in Dev mode and the admin token is already set through Localtonet's Settings. The Dev to Enterprise mode switch only matters if you installed McpNet Gateway standalone via NuGet or GitHub, where Dev mode with no authentication is the default.
Can I use a custom domain instead of localto.net?
Yes. The Domain dropdown on the MCP Gateway tunnel page accepts custom domains you've added through DNS Manager.
Will remote AI agents see all my upstream MCP servers through the tunnel?
Only if you let them. Set AllowedServerIds or AllowedGroupIds on each client's bearer token. Leaving both empty grants access to everything, so scope it deliberately.
Why is the first tool call slow right after I open the tunnel?
If an upstream server runs via npx, its package downloads on first connect, which can take 60 to 120 seconds. This is a McpNet startup cost, not tunnel latency, and resolves on the next background refresh about 60 seconds later.
Does the tunnel handle McpNet's session header correctly?
Yes. Localtonet forwards all headers transparently, including Mcp-Session-Id, which McpNet uses for its 24 hour session TTL. No special configuration is needed on either side.
Can I run multiple MCP Gateway tunnels on separate machines?
Yes. Install Localtonet on each machine and create a separate MCP Gateway tunnel for each, each with its own subdomain and auth token.
What happens if an agent exceeds the rate limit through the tunnel?
McpNet returns JSON RPC error code -32029. The tunnel itself has no separate rate limiting, so this is entirely controlled by McpNet's RateLimitPerMinute settings.
Ready to Expose Your MCP Gateway?
Go to the MCP Gateway page, grab the latest Localtonet client, and get your public endpoint in minutes. No credit card required.
Get Started Free →
