Monitor servers that aren't on the internet.

Plenty of MCP servers never accept a network connection. They run over stdio on a workstation, or inside a private network with no route in from outside. A cloud prober can't reach them — by design, and that's usually the point.

The bridge is a small agent you run next to those servers. It talks to them locally, and reports their health and inventory outbound to MCPatrol. Nothing listens on a public port, nothing is exposed, and no inbound firewall rule is needed.

What you need

• A machine that can reach the servers — your workstation, a jump box, a container in the same network.
• A MCPatrol account with the cloud backend connected in the app.
• Outbound HTTPS from that machine. That's the only network requirement.

Setting it up

1. Get the agent. One self-contained file — no .NET, no runtime, no installer. Windows, macOS and Linux builds are published with each release. Ask [email protected] for the current build while public downloads are being set up.
2. Get your config from the app. Open MCPatrol → Manage → PC bridges → Copy bridge.json. The app fills in your backend URL and mints a bridge-scoped key, so there's nothing to look up. Save it as bridge.json in %LOCALAPPDATA%\MCPatrol\ on Windows, or ~/.local/share/MCPatrol/ elsewhere. Run the agent with no config and it creates the folder and prints the exact path.
3. List your servers in that file — a name and the command that starts each one (see the shape below).
4. Run it. The machine appears under PC bridges within a minute, and its servers join your estate alongside the hosted ones.

The config

What the app copies, with your own values filled in:

{
  "backendUrl": "https://your-backend...",
  "apiKey": "moc_...",
  "machine": "my-machine",
  "servers": [
    {
      "name": "filesystem-mcp",
      "command": "npx",
      "args": "-y @modelcontextprotocol/server-filesystem /path"
    }
  ]
}

The key in that file is bridge-scoped: the backend refuses it on every route except the bridge ones. If the file leaks, what the finder gets is the ability to register a bridge and upload traffic for your account — not to read your estate, delete a server, or reach anything else. Treat it as a secret regardless; it is plain text on disk.

Remote restart, and its limits

MCPatrol can show a restart button for a bridged server. The command sent from the cloud contains only a kind (restart) and a server name — never a command line. The agent looks that name up in your own bridge.json and runs the restartCommand you wrote there. Nothing else, and no other kind of command is implemented.

So the furthest a compromised backend could reach is a restart command you had already written, for a server you had already listed. It cannot make your machine run something you did not put in that file yourself. Leave restartCommand out and the button simply reports that none is configured — monitoring works fine without it.

What it does not do

• No inbound connections, no open ports, nothing listening. It starts every conversation, outbound over HTTPS.
• No auto-update. It does what the build you downloaded does.
• No analytics SDK, no crash reporter, no usage tracking.
• No access to servers you did not list in bridge.json.
• Installs no service, writes no registry keys. Delete the file and it is gone.

What it sends

• Health state, latency, and the server's tool/resource/prompt inventory — the same things the cloud prober records for a public server.
• Per-request traffic metadata (method name, size, duration) when you run it in shim mode.
• Request and response bodies only if you explicitly turn payload capture on. It's off by default, and payloads are redacted before they leave the machine.

It never opens an inbound port, and it never sends the contents of files or environment variables. Details in the privacy policy.

Questions? Contact.