Show HN: MCP Gateway – Zero-Trust Access to MCP Tool Servers

[michaelquigley]

MCP servers work great locally over stdio... until you need one on another machine, or want to share tools across a team. Most approaches to that involve exposing endpoints and managing network access. I built a tool that keeps remote MCP as simple and secure as local stdio.

mcp-bridge wraps any stdio MCP server in one command and shares it over a zrok/OpenZiti overlay. mcp-gateway aggregates multiple backends... local stdio servers and remote shares... into a single connection with a unified, namespaced tool registry. Permission filtering removes tools from the schema entirely... they're not checked at runtime, they're gone from the registry. No listening ports, no VPN, no port forwarding. Your MCP server doesn't change.

Go, Apache 2.0, single binaries, part of the OpenZiti project. Works seamlessly with the llm-gateway I introduced a couple of weeks ago.

[willamhou]

Gateways and signatures solve different problems. A gateway controls access; a signature lets the server verify what request was actually sent. That matters for replay, tamper, and forgery cases after the request passes the edge.

We've been using per-tool-call Ed25519 receipts for this in MCP flows. Verification happens directly in the server handler instead of adding another proxy hop. You can also add a server co-signature if you want proof of what the server received and responded.

[michaelquigley]

This happens in the OpenZiti layer for mcp-gateway. The overlay has strong identity and end-to-end encryption. So by simply wrapping any standard MCP server with mcp-gateway, you've got all of that and more, without having to change your implementation.