Give remote MCP clients a reachable endpoint while keeping inbound router ports closed
A locally running McpNet Gateway is convenient for development, but remote AI tools cannot normally reach an endpoint bound to a private network. A Localtonet MCP Gateway tunnel publishes that gateway through an outbound connection to a Localtonet relay, so the host does not need a public IP address, inbound router port forwarding, firewall changes, or a separate VPN setup. This guide explains the connectivity model, the documented tunnel lifecycle, and the security controls that still belong to your gateway and application. It also clarifies that endpoint exposure does not provide AI model access, provider credentials, request routing, or model credits.
Why a local MCP Gateway needs a connectivity layer
Model Context Protocol tools and gateways are often developed on a workstation, home lab, or private server. The process may listen on localhost or on an address inside a private LAN. That arrangement works for clients running on the same machine or network, but an authorized client elsewhere on the internet cannot directly route to a private address.
One traditional response is to create an inbound router rule and forward a public port to the gateway host. That approach requires control of the network edge, a suitable public IP arrangement, and careful firewall configuration. It may also be unavailable behind carrier-grade NAT, in a shared office, or on a network where the developer is not permitted to modify the router.
Localtonet uses a different connection direction. The Localtonet client application runs on the device that can reach the local service and establishes an outbound connection to a Localtonet relay server. The resulting tunnel supplies a public URL or public host and port, depending on the tunnel type. No unsolicited inbound connection needs to be opened directly from the router to the development machine.
What Localtonet provides, and what it does not
It is important to separate network reachability from the AI services behind an MCP workflow. Localtonet provides the tunneling layer that carries traffic between a public endpoint and a service reachable from the connected client device. The local McpNet Gateway continues to define which MCP servers, tools, or resources are available and how requests are processed.
Localtonet should not be treated as a source of model-provider accounts, API credentials, inference credits, or model routing unless a separate product feature explicitly documents those capabilities. No such claim is needed for this workflow. If your gateway invokes an external AI provider, you must configure a valid provider account and credentials according to that provider's requirements. Any associated usage and billing remain separate from tunnel connectivity.
| Responsibility | Handled by | Practical meaning |
|---|---|---|
| Public endpoint connectivity | Localtonet tunnel | The relay makes the locally reachable gateway available through an assigned public endpoint while the client and tunnel are running. |
| MCP tool and resource behavior | McpNet Gateway and its backends | The gateway decides which MCP capabilities exist and how requests are sent to configured services. |
| Client authentication | Gateway or application access layer | The public endpoint should require appropriate authorization rather than relying on an unguessable address. |
| AI provider credentials | Gateway, application, or protected secret store | Provider keys must be acquired separately and must not be placed in public URLs, documentation, logs, or Localtonet device tokens. |
| Provider usage and billing | Selected AI provider | A tunnel transports requests but does not include provider credits or alter the provider's account terms. |
| Exposure duration | Localtonet client and tunnel lifecycle | Availability depends on the selected device remaining connected and the tunnel remaining in its running state. |
A Localtonet tunnel gives a remote client a network path to the configured target. It does not automatically decide who may call the MCP endpoint, which tools a caller may execute, or which local resources those tools may read or modify. Apply those controls in the gateway and application layers.
Prepare the gateway before public exposure
First confirm that the McpNet Gateway is running and behaves correctly from the same device that will run the Localtonet client. Test its expected endpoint locally and verify that only the intended tools and resources are enabled. If the gateway can reach file systems, databases, source repositories, shell commands, or internal APIs, review each capability as though an external client will attempt to use it.
Least privilege is especially important for AI-agent endpoints because an authorized request can trigger actions rather than merely retrieve a web page. Prefer narrowly scoped tool permissions, read-only access where writing is unnecessary, restricted directories, limited service accounts, and separate development credentials. Do not expose broad administrative capabilities merely because the first remote client is trusted.
Authentication should be enforced before accepting sensitive operations. The exact mechanism depends on the McpNet Gateway and client configuration, so it should be verified against the gateway's current documentation. Avoid placing secrets in query strings or public endpoint names. Provider API keys, gateway bearer tokens, Localtonet device tokens, and other credentials must be treated as separate secrets and must never be copied into an article, support ticket, public repository, or shared screenshot.
Do not expose an unauthenticated gateway that can invoke sensitive tools or access private data. Require appropriate authentication, grant each client only the capabilities it needs, and review tool-level permissions before starting the tunnel. A public URL is an address, not an access-control policy.
How to expose the local McpNet Gateway
The workflow below follows the documented Localtonet lifecycle: run the client, identify the device, select a current relay, create the appropriate configuration, start it, and manage its running state. Dashboard names and available server values can change, so use the current product interface rather than copying a hardcoded server code from a third-party guide.
Install and run the Localtonet client
Install the Localtonet application for the operating system on the device that can reach the running McpNet Gateway. Keep the client running because the tunnel depends on its outbound connection to the relay.
Authenticate and select the gateway device
Use the device-specific authentication token through the supported product workflow, then select that connected device for the tunnel. Never guess, publish, or reuse another device's token.
Select an available relay server
Choose a relay server or region from the values currently shown by Localtonet. Availability can vary, so do not rely on a server code copied from an old article or configuration example.
Create the MCP Gateway tunnel
Create the MCP Gateway tunnel for the locally running McpNet Gateway and provide the target details requested by the current dashboard. Confirm that the selected Localtonet device can reach that target before continuing.
Start the tunnel and test the endpoint
Use the Start action after creating the configuration. Creation alone does not make a tunnel run. Test the assigned public endpoint with an authorized remote client and verify both allowed and denied operations.
Stop or delete the tunnel when finished
Stop the tunnel when remote access is no longer required, or delete the configuration if it will not be reused. Also stop the local gateway when appropriate and rotate credentials if they may have been disclosed.
For product-specific background on this capability, see the Localtonet guide to exposing an MCP Gateway . Confirm the current dashboard fields and availability before applying instructions from any older workflow.
Validate the endpoint safely
A successful connection test should cover more than whether a client receives a response. Begin with an identity that has minimal privileges. Verify that the client can discover or invoke only the intended tools, that unauthorized requests fail, and that malformed input does not reveal credentials or internal paths. If separate clients require different capabilities, use distinct identities or authorization policies rather than sharing one unrestricted credential.
Review the gateway's own logs and the downstream services it calls. Avoid logging authorization headers, provider keys, complete prompts containing sensitive data, or private tool output. If an MCP tool can modify data, test it against a disposable development resource before allowing it near production systems.
The tunnel remains available only while the selected Localtonet client is connected and the tunnel is running. That property provides a clear operational shutdown mechanism, but it should not replace authentication. If the client disconnects unexpectedly, remote connectivity ends until the required connection and tunnel state are restored.
Operational practices for remote AI-agent endpoints
Frequently asked questions
Do I need to open a router port for an MCP Gateway tunnel?
No. The Localtonet client establishes an outbound connection to a Localtonet relay. This allows the tunnel to provide a public endpoint without inbound router port forwarding, firewall changes, a public IP address, or a separate VPN setup.
Does creating the tunnel immediately make the gateway public?
No. Creating a tunnel and running it are separate lifecycle states. The selected Localtonet client must be connected, and you must use the Start action before the public endpoint becomes available.
Does Localtonet authenticate MCP users automatically?
The tunnel provides connectivity, not a complete MCP authorization policy. Configure authentication and least-privilege tool access in the gateway or application layer, and test that unauthorized requests are rejected.
Does the tunnel include AI model credits or provider API access?
No such capability is part of this tunneling workflow. AI provider accounts, API keys, model availability, usage charges, and billing remain separate. Localtonet supplies the network path to the local gateway.
What happens if the Localtonet client disconnects?
The tunnel is available only while the selected client device is connected and the tunnel is running. If the client disconnects, the public endpoint cannot continue forwarding traffic to the local gateway through that tunnel.
Should I put a provider key or Localtonet token in the public URL?
No. Never place device tokens, provider keys, gateway credentials, or other secrets in public URLs. Store each credential through the appropriate protected mechanism and rotate it if accidental disclosure occurs.
Publish your local MCP Gateway with controlled access
Run Localtonet on the device that can reach your McpNet Gateway, create the appropriate tunnel, verify gateway authentication and least-privilege permissions, then start the endpoint only when remote access is required.
Get Started Free →
