What it does
Some MCP clients, Claude Desktop among them, run their connectors in a sandbox. A connector in that sandbox can reach 127.0.0.1 but not LAN addresses. This is true even with the macOS Local Network permission turned on. The sandbox is a security boundary by design, not a bug. If you give the connector a LAN IP for fldigi or N3FJP, it times out, even though telnet to the same IP works. The relay runs outside the sandbox, on the same computer as the client. It listens on loopback and forwards to the remote service. You point the connector at 127.0.0.1, and the bridge makes the hop to the LAN.
The problem comes from the client's environment, not from any one MCP server. That is why the workaround is a separate tool that works with any server, instead of being built into one of them.
Features and benefits
| Feature | What it gives you |
|---|---|
| Loopback-to-LAN relay | Relays TCP and UDP, with one command per service. Several bridges can run side by side. Each one is identified by its service name. |
| Standard library only at runtime | The relay has no third-party dependencies. It does not modify or inspect traffic. |
| Presets | n3fjp = 1100 (TCP), fldigi = 7362 (TCP), wsjtx = 2237 (UDP). Add your own in ~/.mcp-host-bridge/services.ini. |
| Custom services | A program with no preset needs only a port: mcp-host-bridge install myapp --port 5000 --to 192.168.1.9. |
| Status check | mcp-host-bridge status <service> checks the bridge and tests the connection. |
| UDP listen-and-deliver | UDP has no connections and runs in both directions, so the bridge works the other way round. It listens on the LAN side and delivers to loopback. Control replies go back to the address the datagram came from, which the bridge learns by itself. |
| Persistence per OS | macOS: launchd LaunchAgent, per-user, RunAtLoad and KeepAlive. Windows: netsh interface portproxy for TCP, with no Python required. UDP uses a Scheduled Task running the relay, and TCP falls back to one if netsh is unavailable. Linux: systemd --user service with Restart=always. The same commands work on every OS. |
| Binaries with no Python | Download one file for your OS from the releases. The installed service runs that binary directly. |
How it works
For TCP, the bridge listens on loopback and connects out to the remote program. For UDP it works the other way round. WSJT-X broadcasts datagrams in, and control replies must go back to the address each datagram came from. The bridge learns the remote address from the first datagram it receives, or you set it with --to.
Install it
mcp-host-bridge is not an MCP server, so there is nothing to ask the assistant. You install it once, from a terminal on the same computer as your MCP client.
Get the bridge
Download the single file for your OS from Downloads: mcp-host-bridge-macos, mcp-host-bridge.exe or mcp-host-bridge-linux. No Python is needed. Or install it with Python:
pipx install mcp-host-bridge # or: uvx mcp-host-bridge ...
# or from source:
git clone https://github.com/sbrunner-atx/mcp-host-bridge.git
cd mcp-host-bridge && uv sync && uv run mcp-host-bridge --helpThe release binaries are not code-signed. On macOS, right-click the file and choose Open once, or run xattr -d com.apple.quarantine ./mcp-host-bridge-macos. On Windows, choose More info, then Run anyway.
Install a bridge
Run one command per program. The service starts again after a reboot.
mcp-host-bridge install n3fjp --to 192.168.1.50 # TCP 127.0.0.1:1100 -> 192.168.1.50:1100
mcp-host-bridge install fldigi --to 192.168.1.50 # TCP 127.0.0.1:7362 -> 192.168.1.50:7362
mcp-host-bridge install wsjtx --to 192.168.1.111 # UDP 0.0.0.0:2237 -> deliver 127.0.0.1:2238Then, in the MCP connector settings, set the service host to 127.0.0.1, save, and fully quit and reopen the client. For WSJT-X, set wsjtx-mcp to 127.0.0.1 port 2238, and point WSJT-X's UDP Server at this host's LAN IP, port 2237.
Tools
| Command | What it does |
|---|---|
install <service> --to HOST | Persistent service (survives reboot), using a built-in preset. |
install <name> --port N --to HOST | A custom app with no preset: give it a port. |
status <service> | Check it and test the connection. |
uninstall <service> | Remove it. |
run <service> --to HOST | Run in the foreground instead of installing a service. |
list-services | See known presets. |
Built-in OS alternatives
Forwarding a port like this is a standard networking task. If you would rather not install anything, you can set up the same hop from loopback to the LAN by hand:
- Windows:
netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=1100 connectaddress=192.168.1.50 connectport=1100 - macOS and Linux:
socat TCP-LISTEN:1100,bind=127.0.0.1,fork,reuseaddr TCP:192.168.1.50:1100 - Anywhere with SSH:
ssh -N -L 127.0.0.1:1100:192.168.1.50:1100 user@host
mcp-host-bridge does the same with one command that works on every OS. It adds presets, and it keeps the relay running after a reboot.
Settings
| Flag | Meaning |
|---|---|
--to HOST[:PORT] | Remote host (or host:port). Port defaults to the preset's port. |
--port N | Define or override the service port. |
--listen HOST:PORT | Local address to listen on (default 127.0.0.1:<port>). |
--name LABEL | Instance label (defaults to the service name). |
UDP services use a --listen (LAN-facing) and --deliver (loopback) pair instead. UDP listen defaults to 0.0.0.0:<port> and deliver to 127.0.0.1:<port+1>. You can override either side with --listen or --deliver.
Custom presets go in ~/.mcp-host-bridge/services.ini. A line name = port defines a TCP service, and name = port udp (or port,udp) defines a UDP service. The file is optional. Your entries override the built-in presets.
Safety
The bridge passes bytes through with no authentication and no encryption. Use it only on a trusted LAN. The device APIs it forwards to (N3FJP, fldigi, WSJT-X) make the same assumption. It does not modify or inspect traffic.