Install the Windows core, create a profile-bound client credential, verify MCP locally, and expose it without confusing reachability with authorization
MCPProxy gives compatible AI clients one connection to a managed set of MCP servers. This guide installs the official Windows build, keeps the core and tray processes distinct, adds upstream servers, creates a scoped mcp_cli_ credential through the current Clients or Connect workflow, and tests both successful and rejected MCP connections. It then connects the verified listener to a Localtonet HTTP tunnel without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. Because MCPProxy serves its web interface, MCP routes, and management APIs from the same HTTP service, the guide also explains exactly what a tunnel changes and when you should not publish the listener directly.
📋 What's in this guide
Understand the MCPProxy and Localtonet architecture
MCPProxy is an open-source, local-first MCP proxy for connecting compatible AI clients to multiple Model Context Protocol servers through one managed service. You configure upstream servers once, organize access with profiles, and connect each client using its own scoped credential. The core is distributed as a single binary for Windows, macOS, and Linux, with the web interface embedded in that binary.
The official Windows installer includes two different executables:
mcpproxy.exeis the core process that hosts the HTTP service, MCP endpoints, embedded web interface, and upstream connections.mcpproxy-tray.exeis the Windows system tray application installed for desktop convenience.
These components must not be treated as the same process. Running mcpproxy serve starts the core service. The available evidence confirms that the Windows installer also installs a tray executable and Start Menu shortcuts, but it does not establish that launching the CLI command automatically launches or presents the tray application. If you want the tray interface, start it separately from the installed shortcut or executable and confirm its status independently.
Localtonet adds a separate network layer. Our client runs on the Windows device, establishes an outbound connection to a Localtonet relay, and forwards requests from a public HTTPS address to the local MCPProxy listener. The tunnel does not start MCPProxy, approve upstream tools, create an MCPProxy client, or replace MCPProxy authentication.
mcp_cli_ credential for current MCP endpoints instead of placing the administrator API key in client configuration.
The tunnel reaches an HTTP service, not only one MCP path
MCPProxy serves several surfaces from the same HTTP listener. Current v0.70.0 release information identifies the MCP routes /mcp, /mcp/call, /mcp/code, and /mcp/all. The embedded web interface and management or REST functionality are also delivered by the core HTTP service.
A Localtonet HTTP tunnel configured for that listener forwards requests addressed to the public hostname toward the listener. It should therefore be treated as making the listener's HTTP route space network-reachable, not as publishing only /mcp. An mcp_cli_ credential is explicitly limited to MCP endpoints. It is not an administrator credential and should not be assumed to protect or authorize the embedded management interface.
The verified Localtonet workflow in this guide targets an IP address and port. We do not have verified evidence of a Localtonet HTTP path allowlist for this setup, so do not assume the tunnel publishes only /mcp. Before exposing the listener, confirm how your installed MCPProxy version protects its web and management routes. If you require a public endpoint that can reach only selected MCP paths, place a separately reviewed route-filtering gateway in front of MCPProxy or do not expose the shared listener publicly.
For the strictest boundary, keep MCPProxy local and use a private access design instead of a public HTTP tunnel. Localtonet's VPN Manager is the Localtonet feature intended for a private mesh network. Standard HTTP tunneling is public reachability and must not be described as a VPN.
Prerequisites and current documentation
Use the signed Windows installer unless you have a specific reason to manage a standalone binary. The official download page provides separate Windows x64 and ARM64 installers. Most 64-bit Intel and AMD Windows systems use x64. Windows devices built around an ARM processor require ARM64.
Open these official project pages before installation:
- Official MCPProxy Windows download page, which presents the current Windows x64 and ARM64 installers.
- MCPProxy v0.70.0 release notes, including profile enforcement, per-client credentials, Windows installers, and the downgrade warning.
- Official MCPProxy repository and current quick start.
- Current MCPProxy documentation directory for client-specific connection and operational details.
The current supplied release evidence identifies v0.70.0 as the latest release. Check the release page when you perform the installation because a newer stable version may have changed client connection details, listener behavior, route names, or security requirements.
Prepare the following:
- A Windows x64 or ARM64 computer.
- Permission to install software into Program Files.
- A new PowerShell or Windows Terminal session after installation.
- A browser for the embedded MCPProxy interface.
- At least one upstream MCP server that you understand and trust.
- Any runtime required by that upstream, such as its documented Python, Node.js, container, or standalone executable environment.
- A compatible MCP client for protocol-level tests.
- A Localtonet account and client only when the local deployment has passed its security and functional checks.
The official installer provides the packaged Windows binaries. This revision does not state a Go version requirement or provide a source-install command because those details are version-sensitive and are unnecessary for the recommended Windows installer workflow.
Likewise, do not create a configuration file from an old example before starting the current release. Configuration locations and schemas can change. Use the installed version's embedded interface and current documentation unless you have verified the exact file format for that release.
Install MCPProxy on Windows
Download the matching official installer
Visit the official MCPProxy download page and select Windows x64 for a 64-bit Intel or AMD computer, or Windows ARM64 for an ARM-based Windows computer. Avoid unofficial executable mirrors.
Run the Windows setup wizard
Open the downloaded installer and follow its prompts. Approve it only when the package and publisher match the official distribution you intended to install.
Confirm the packaged components
The installer places the core mcpproxy.exe and tray mcpproxy-tray.exe executables under Program Files, adds MCPProxy to the system PATH, and creates Start Menu shortcuts.
Open a new terminal
Close any terminal opened before installation and start a new PowerShell or Windows Terminal session. An existing terminal may not see the updated PATH.
Start the core service
Run the documented serve command and keep the terminal visible during the first startup. Record the actual listener address and port reported by the installed version rather than assuming an address from an older example.
mcpproxy serveDo not infer that the tray application started because the core command remains running. If you want the Windows tray interface, launch the installed tray shortcut separately. Conversely, seeing a tray icon is not a substitute for confirming that the core HTTP service is listening.
Silent installation
The official Windows installer supports the following silent-install switch:
.\mcpproxy-setup.exe /VERYSILENTThe downloaded filename normally includes a version or architecture, so use the actual local filename. Silent installation does not remove the need for organizational approval, package verification, post-installation security configuration, or functional testing.
Determine the real local listener
Older examples commonly show 127.0.0.1:8080, and that is the target illustrated in this tutorial's existing diagrams. However, the supplied current public evidence does not establish a universal default listener for every release or installation state. Treat the startup output and the installed version's interface as authoritative.
If the current process confirms that it is listening on 127.0.0.1:8080, use:
http://127.0.0.1:8080
If it reports a different loopback port, substitute that confirmed port throughout the browser, MCP client, and Localtonet configuration. Do not point a tunnel at port 8080 merely because it appears in an illustration.
Do not widen the listener to every network interface just to use Localtonet. When our client runs on the same computer, it can reach a loopback listener directly. A wider bind can expose MCPProxy to the local network and may alter Windows Firewall behavior.
Add upstream servers and create a least-privilege profile
Open the embedded web interface at the base address reported by the core process. For a confirmed 127.0.0.1:8080 listener, that would be http://127.0.0.1:8080. Use the current Add Server workflow to enter the settings required by your real upstream MCP server.
Do not copy a fictional Python command or placeholder HTTP URL and expect it to work. A local stdio upstream requires its executable, runtime, arguments, working environment, and any supported secrets to be available to the Windows account running MCPProxy. A remote HTTP upstream must already be reachable at its configured URL and must use the transport and authentication expected by that server.
MCPProxy places new servers into review workflows according to its configured trust mode. Quarantine and scanning reduce exposure to unexpected tool definitions, but they do not prove that an implementation is safe. Review the upstream's source, publisher, requested secrets, filesystem access, network destinations, and possible side effects before approval.
Create a profile for the remote client
MCPProxy v0.70.0 profiles enforce policy across discovery and execution surfaces. A profile can select the servers a client may reach, cap the maximum tool tier as read, write, or destructive, allow or deny individual tools with server and tool patterns, decide how unannotated tools are treated, and disable code execution or management tools.
Create a purpose-specific profile before creating the remote client. A sensible first test profile should include only the upstream server needed for testing and should avoid destructive capabilities. If the test client only needs read-oriented tools, cap the profile accordingly. Do not use an unrestricted administrator context simply because it is faster to configure.
Create a profile-bound MCP client credential
Current MCPProxy releases use the Clients or Connect workflow to issue a separate credential for each client. In v0.70.0, Connect no longer writes the administrator API key into client configurations. It creates an mcp_cli_ credential bound to a profile and valid on MCP endpoints only.
Open Clients or Connect
In the embedded MCPProxy interface, open the current Clients hub or the Connect workflow. Use this interface instead of copying an administrator key into an AI client's configuration.
Choose the intended client
Select the supported AI client or connection workflow you intend to use. Client configuration formats differ, so follow the instructions generated for that client.
Bind the client to the restricted profile
Select the purpose-specific profile created for this connection. Profile pinning prevents the resulting client session from switching beyond that profile's boundary.
Generate the client configuration
Complete Connect so MCPProxy creates the client's mcp_cli_ credential and supplies the applicable client configuration or connection instructions. Use that generated method to provide the credential to the client.
Protect and test the credential
Treat the credential as a secret. Do not paste it into screenshots, articles, repositories, shared logs, support posts, or AI prompts. Keep enough administrative information to identify and revoke the client without recording the secret in an unsafe location.
The exact field or header used to carry a credential is client and transport specific. Do not invent a generic JSON property or manually translate it into an administrator header. Use the Connect-generated configuration and the current MCPProxy client connection documentation for the selected client.
The Clients hub can rotate or forget a client credential. Use one credential per client so that access can be revoked without disrupting unrelated clients. If a device is lost, a client is retired, or a credential appears in an unsafe location, revoke or rotate that client immediately.
v0.70.0 reports existing client configurations that still contain the administrator key but does not rewrite them automatically. Use the documented Upgrade clients holding the admin key workflow, then rotate the administrator key. A profile-bound mcp_cli_ credential is the correct credential category for MCP client access.
Verify the core, web interface, upstreams, and MCP authentication locally
Local verification must cover more than a browser page. Test each layer separately so that a successful web interface does not hide an unavailable upstream or an unauthenticated MCP endpoint.
| Layer | What to verify | What success does not prove |
|---|---|---|
| Core process | mcpproxy serve remains running and reports a listener. |
It does not prove the tray, upstreams, or remote tunnel are healthy. |
| Windows tray | The separately launched tray process opens and reports its own state. | A tray icon alone does not prove MCP protocol health. |
| Embedded web UI | The base listener address opens locally. | A rendered page does not prove an MCP initialize exchange or tool call works. |
| Upstream server | The intended server is connected, reviewed, and healthy. | One healthy upstream does not establish that every configured server works. |
| MCP authorization | A client with its generated mcp_cli_ credential can initialize within its profile. |
Authorization does not establish that every allowed tool is safe. |
| Negative authentication | The same MCP connection fails when the credential is removed or invalid. | A rejected MCP request does not prove management routes are inaccessible. |
Confirm the core remains running
Inspect the terminal running mcpproxy serve. Resolve startup, configuration, migration, or port errors if the process exits.
Open the local web interface
Browse to the exact base address reported by the core. This checks the listener and embedded interface, but it is not a complete MCP test.
Check the selected upstream
Confirm that the intended upstream is connected and not blocked by an unresolved quarantine or review state. Correct missing runtimes, commands, URLs, secrets, or server-specific errors before continuing.
Connect with the authorized client
Use the configuration created by Connect. For v0.70.0, the primary MCP route is documented as /mcp. Do not add a trailing slash solely because an older example used one.
Run a low-risk allowed operation
Initialize the connection, confirm that discovery reflects the assigned profile, and invoke a deliberately low-risk tool. Check that tools outside the profile are absent or refused.
Repeat without valid credentials
Duplicate the client configuration for testing, remove or invalidate the MCP client credential, and attempt the same connection. The MCP request must be rejected. If it succeeds, do not create a public tunnel.
Use an actual compatible MCP client for both positive and negative tests. An ordinary browser request does not perform the MCP initialization sequence, and a web page loading successfully is not evidence that unauthorized MCP requests are blocked.
If a client without a valid mcp_cli_ credential can initialize or use MCP tools, the application boundary is not ready for public reachability. Confirm that MCP authentication is required, review the installed release and configuration, and repeat the local negative test before proceeding.
Create the Localtonet HTTP tunnel
Proceed only after the authorized local MCP connection works, the unauthenticated connection is rejected, the upstream is healthy, and you have reviewed the shared-listener exposure described earlier.
The instructions below use 127.0.0.1 and port 8080 only when MCPProxy has actually reported that listener. If your current installation reports another loopback port, use the reported value instead.
Install and run the Localtonet client
Run our client on the Windows computer hosting MCPProxy. A same-host installation lets the tunnel reach MCPProxy through loopback without widening the application listener to the LAN.
Authenticate or select the Windows device
Use the device-specific authentication token from your Localtonet account. Never put this token in a screenshot, article, public repository, shared script, or MCP client configuration.
Select an available relay server
Choose from the server or region options currently shown in the Localtonet dashboard. Do not copy a server code from another account or an old tutorial, and do not assume every option is available with every plan.
Create an HTTP tunnel
Select the HTTP tunnel family and set the local target to the loopback IP and port confirmed by MCPProxy. For the commonly illustrated listener, use IP address 127.0.0.1 and port 8080. Select an available Process Type from the current dashboard.
Review and start the tunnel
Check the selected device and local target, then press Start. Creating the tunnel does not start it automatically.
Record the assigned public HTTPS address
Use only the address displayed for the running tunnel. Do not publish that address together with an MCPProxy credential or Localtonet device token.
See our Localtonet HTTP tunnel documentation for the current dashboard workflow. Process Types for HTTP tunnels can provide a random subdomain, a supported custom subdomain, or a custom domain. Check the live dashboard and current documentation rather than assuming the availability of a particular option.
If the assigned base address is represented as https://your-assigned-address.example, the v0.70.0 primary MCP URL is formed as:
https://your-assigned-address.example/mcp
The hostname is a placeholder. Use the actual HTTPS address shown for your tunnel. Current v0.70.0 release information refers to /mcp without a trailing slash, so do not preserve an older /mcp/ form unless the documentation for your installed version or selected client explicitly requires it.
Test the public base URL separately from the MCP route. If the embedded interface loads, the tunnel is demonstrably reaching more than the MCP path. Do not interpret an mcp_cli_ rejection on /mcp as proof that every web or management route is appropriately protected.
Verify authorized access and reject unauthenticated remote requests
Remote verification should prove four separate facts: the tunnel is running, the public MCP route reaches MCPProxy, the profile-bound credential is accepted, and the same connection is rejected without a valid credential.
Confirm the Localtonet lifecycle state
Verify that the correct Windows device is connected and that the HTTP tunnel is running. A saved tunnel configuration is not enough.
Change only the client URL
In a copy of the working authorized client configuration, replace the local MCP base with the public HTTPS MCP URL. Preserve the Connect-generated credential mechanism and the assigned profile.
Complete an authorized MCP connection
Initialize through the public URL, confirm the expected profile-scoped discovery result, and run the same low-risk tool used during local verification.
Test the public URL without credentials
Use a separate test configuration with the credential removed or invalidated. Attempt the same MCP initialization through the public URL and confirm that MCPProxy rejects it.
Test profile enforcement
Attempt to discover or invoke a tool deliberately excluded by the profile. It should remain hidden or be refused according to the current profile policy.
Review activity and close temporary access
Inspect the recorded request outcome in MCPProxy. If the tunnel was created only for testing, stop it after verification and revoke the temporary client credential if it is no longer needed.
Record the outcome without recording secrets. Useful operational evidence includes the installed MCPProxy version, profile name, Localtonet tunnel identifier, test time, permitted low-risk operation, negative authentication result, and whether the public root interface was reachable.
Operate, update, and troubleshoot the deployment
Recommended startup order
- Start the MCPProxy core with
mcpproxy serve. - Confirm the actual loopback listener and open the local web interface.
- Confirm the required upstream server is healthy and reviewed.
- Verify an authorized local MCP connection.
- Verify rejection of a local connection without valid MCP credentials.
- Start or confirm the Localtonet client on the correct Windows device.
- Start the configured Localtonet HTTP tunnel.
- Repeat the positive and negative MCP tests through the public HTTPS URL.
When removing access, stop the Localtonet tunnel first. Then stop the MCPProxy core according to how you launched it. Closing only the tray application may not stop a separately running core process, and stopping the core does not delete the saved Localtonet tunnel.
v0.70.0 downgrade warning
require_mcp_auth: true before downgrading to v0.69 or earlier
Older MCPProxy binaries do not understand the newer mcp_cli_ credential type. The v0.70.0 release notes warn that downgrading with MCP authentication disabled can grant those credentials unconfined access. Apply the documented require_mcp_auth: true protection before the downgrade, verify the resulting configuration with the target version's documentation, and repeat both authorized and unauthenticated tests before restoring any public tunnel.
Treat an upgrade or downgrade as a security change, not merely a binary replacement. Back up the supported configuration, record the current version and profile behavior, stop public reachability during the change, and read the target release notes. v0.70.0 also changes profile enforcement and client credential handling, so scripts should not parse human-readable CLI tables when a documented JSON output is available.
Troubleshooting by layer
| Symptom | Likely layer | What to check |
|---|---|---|
mcpproxy is not recognized |
Windows installation or PATH | Confirm the installer completed, verify the architecture, and open a new terminal after installation. |
| The serve command exits | Core process | Read the terminal error and resolve configuration, migration, permission, or occupied-port problems before testing the browser. |
| The tray icon is absent | Tray application | Launch the installed tray shortcut separately. Do not assume mcpproxy serve starts it. |
| The tray exists but the browser fails | Core listener | Confirm that the core process is running and use the exact listener address it reports. |
| The web interface works but a server is unhealthy | Upstream MCP server | Check its executable, runtime, arguments, URL, secrets, process state, quarantine, and review status. |
| An authorized client cannot connect locally | Client configuration or MCP authentication | Use the Connect-generated configuration, confirm the current /mcp path, check that the credential is active, and verify its assigned profile. |
| An unauthenticated MCP client succeeds | Application security boundary | Stop the tunnel, require MCP authentication, review the installed version, and do not resume public access until the negative test is rejected. |
| The client connects but a tool is missing | Profile, discovery, or quarantine | Check the selected servers, maximum tier, allow and deny rules, unannotated-tool policy, quarantine state, and upstream health. |
| Local MCP works but the public URL fails | Localtonet lifecycle or target | Confirm the selected device is connected, the tunnel is started, and the target matches the core's actual loopback port. |
| The public web UI opens but MCP fails | MCP URL, transport, or credential | Use the public HTTPS address with the current /mcp route and the Connect-generated client credential mechanism. |
| Remote access stops unexpectedly | Process or tunnel lifecycle | Check the core process, upstream state, Localtonet client connection, and tunnel running state separately. |
The Localtonet target points to the wrong computer
Loopback is interpreted from the Localtonet client's device. If our client and MCPProxy run on the same Windows computer, 127.0.0.1 points to MCPProxy on that computer. If the Localtonet client runs on another device, 127.0.0.1 points back to the other device instead.
Running both applications on the MCPProxy computer is the simplest and narrowest arrangement. A separate tunneling device requires MCPProxy to listen on an address reachable from that device, along with an explicitly reviewed LAN firewall and access policy.
The public root interface is reachable
This indicates that the tunnel reaches the shared HTTP listener, as expected. It does not mean that every management action is unauthenticated, but it does mean the interface and related routes are inside the public network boundary.
Confirm the installed version's management authentication behavior before continued exposure. If your policy requires the management interface to be unreachable from the internet, do not publish the shared listener directly. Use a private network design or a separately reviewed gateway that permits only the required current MCP routes.
Credential rotation and removal
Use the Clients hub to rotate or forget a client credential. Test the replacement credential before revoking the old one when continuity is required. After revocation, repeat a negative test using the old configuration and confirm that it no longer initializes.
Keep the two credential categories separate:
- The Localtonet device token identifies the client device that maintains the tunnel.
- The MCPProxy
mcp_cli_credential authorizes one MCP client within its bound profile.
A Localtonet token must never be placed in an MCP client configuration. An MCPProxy credential must never be used to authenticate the Localtonet client. If either value is exposed, revoke or rotate it through the system that issued it.
Frequently asked questions
Does MCPProxy provide Windows x64 and ARM64 installers?
Yes. The official MCPProxy download page provides Windows x64 and ARM64 installers. The installer includes the core executable and Windows tray executable, adds MCPProxy to PATH, and creates Start Menu shortcuts.
Does running mcpproxy serve launch the Windows tray application?
Do not assume that it does. The command starts the core service. The installer also provides mcpproxy-tray.exe, but the available evidence does not establish that the CLI command automatically launches or presents the tray process. Start and verify the tray separately when you want to use it.
Is MCPProxy always available at 127.0.0.1:8080?
Do not assume a universal default. Use the listener address and port reported by the installed core process. If it confirms 127.0.0.1:8080, use that target consistently. If it reports another port, update the browser, MCP client, and Localtonet target together.
Should the current MCP URL end with a trailing slash?
Current v0.70.0 release information refers to the primary route as /mcp without a trailing slash. Follow the documentation for your installed version and selected client rather than preserving /mcp/ from an older example.
Does the Localtonet tunnel expose only the MCP route?
Do not assume so. The HTTP tunnel targets the MCPProxy listener, which also serves its embedded web interface and management or REST functionality. Treat the listener's route space as network-reachable unless a separately verified route-filtering layer restricts it.
Does the public HTTPS address replace MCPProxy authentication?
No. Localtonet provides network reachability. MCPProxy must authenticate the MCP client and enforce its profile. Create a separate profile-bound mcp_cli_ credential through Clients or Connect, then verify that a connection without that credential is rejected.
Can I keep MCPProxy bound to loopback?
Yes, when the Localtonet client runs on the same Windows computer. Configure the HTTP tunnel with the loopback address and actual MCPProxy port. You do not need to widen the listener to the LAN for this same-host arrangement.
What must I do before downgrading from v0.70.0?
Set the documented require_mcp_auth: true protection before returning to v0.69 or earlier. Older binaries do not understand mcp_cli_ credentials, and the v0.70.0 release notes warn that downgrading with MCP authentication off can grant them unconfined access. Stop public reachability and repeat positive and negative authentication tests after the change.
Why does the browser work while the MCP client fails?
The browser checks the embedded HTTP interface, while the MCP client must use the correct MCP route, supported transport, and valid profile-bound credential. It also depends on upstream health and profile policy. Test those layers separately.
Connect a verified MCPProxy service with Localtonet
Install the current Windows build, create a least-privilege profile and per-client credential, prove that unauthenticated MCP access is rejected, and review the shared HTTP route boundary. When the application is ready, use a Localtonet HTTP tunnel to add controlled public reachability without inbound router port forwarding.
Get Started Free →
