Comparison
mcppipe vs ngrok, for exposing an MCP server
Both put a server running on your machine behind a public HTTPS URL. The difference is not the tunnel — it is whether anything in the path understands the MCP JSON-RPC crossing it.
The short version
If you want a public URL for a local port, ngrok does that, it has done it for years, and it does more than MCP — TCP, TLS and SSH included. If what you are exposing is an MCP server and you want to see the tool calls, refuse the ones you did not approve, and know which tool is slow, that layer is what mcppipe adds. The two are not the same purchase.
What ngrok publishes for MCP
ngrok has an MCP guide. Following it, a tunnel to an MCP server is protected by a bearer token, optionally an IP restriction, and a rate limit applied per endpoint. Their Traffic Policy engine matches on request method, path and headers.
What that means in practice: a policy can decide whether a request reaches your
MCP server, but not which tool the request is calling — a
tools/call for read_file and one for
delete_everything are the same POST to the same path with the same
headers. The distinction lives in the JSON-RPC body.
What mcppipe does with the body
mcppipe parses the JSON-RPC. That single fact is what the rest follows from: allow and deny lists naming individual tools, rate limits scoped to one tool, a pinned hash of each tool definition so a silently-rewritten tool is refused rather than run, field-level redaction of the arguments we record, and latency broken out per tool and method rather than per socket.
It is also the trade. On any tunnel you can flip to zero-knowledge, and then mcppipe relays bytes and reads nothing — and every capability in the paragraph above switches off with it, because none of them can work on bytes we never read. That option exists on every plan, including Free.
Where ngrok is the better answer
- You need more than HTTP. Database ports, SSH, raw TCP or TLS. mcppipe does MCP over Streamable HTTP and nothing else.
- You are not exposing MCP at all. A web app, a webhook receiver, a demo server — none of the protocol-aware layer applies, and you would be paying for machinery you do not use.
- You need a global edge and a decade of operational track record. ngrok has both. mcppipe is new.
- Price is the deciding factor. ngrok's cheapest paid tier is below mcppipe's. If the governance layer is not worth the difference to you, it is not worth the difference.
Plenty of people should run both — ngrok for everything else, mcppipe for the MCP endpoints where the tool-level controls matter.
Side by side
Capability rows only. Where ngrok's documentation does not describe a capability, the cell says so rather than asserting they cannot do it.
| Capability | mcppipe | ngrok | Why it matters |
|---|---|---|---|
| Per-tool allow / deny list | Yes — exact tool names, per tunnel, checked on every tools/call | Not documented; Traffic Policy matches on method, path and headers | A bearer token is all-or-nothing. Either every tool is reachable or none is. |
| Rate limit scoped to one tool | Yes — per (tool, method) | Rate limits are per endpoint / API key | One expensive tool can exhaust a quota that a cheap one shares. |
| Pinned tool definitions | Yes — SHA-256 per tool; drift raises an alert, and refuses the call when blocking is on for that tunnel | Not documented | A server that silently rewrites a tool after you approved it is the rug-pull case. |
| Field-level redaction | Yes — in what we record and show you; upstream still receives the real value | Not documented for request bodies | Arguments carry tokens and paths you may not want in a log. |
| Latency per tool, not per socket | Yes — per (tool, method) | Endpoint-level traffic metrics | Knowing the tunnel is fast does not tell you which tool is slow. |
| Replay a captured call | Yes — a captured tools/call, re-sent with the original or edited arguments | Request inspection and replay, at HTTP level | Both replay. Only one understands the JSON-RPC it is replaying. |
| Resume queued calls across a reconnect | Yes — a 60-second buffer replays the requests still awaiting an answer | Not documented for MCP sessions | A reconnect otherwise drops everything queued behind the broken link. |
| OAuth 2.1 resource server with audience binding | Yes — RFC 9728 + RFC 8707 when you switch the tunnel to OAuth mode | OAuth and OIDC for browser access; bearer tokens for APIs | The MCP spec mandates audience-validated tokens for remote servers. |
| Local traffic inspector | Yes — --inspect, decoded as MCP, on 127.0.0.1:4040 | Yes — request inspection at 127.0.0.1:4040, at HTTP level | Both give you a local view. Only one shows the tool name. |
| A second CLI on the same tunnel | Coexists — newest serves, older sessions stand by; 3 on Free, 10 on Pro | Not documented for concurrent agents on one endpoint | A new connection killing the running one is the failure people hit first. |
| Long tool calls and SSE | Chunked pass-through; 60s to start replying, no ceiling once streaming | HTTP streaming supported | A buffered SSE stream or a gateway timeout kills an agent tool silently. |
| Free tier | 2 tunnels · 100k tool calls · 5 GB per month | 3 endpoints · 20k HTTP requests · 1 GB per month | Different units, so read it as shape rather than a winner. |
| Non-HTTP protocols (TCP, TLS, SSH) | No — MCP over Streamable HTTP only | Yes | If you need a database port or an SSH jump, this is not the tool. |
ngrok capabilities above are drawn from ngrok's own published documentation and pricing page, retrieved July 2026. Products change; if you find something here that no longer matches their docs, email support@mcppipe.dev and we will correct it.
ngrok is a trademark of ngrok, Inc. mcppipe is not affiliated with, endorsed by, or sponsored by ngrok, Inc. Product names are used here solely to identify the products being compared.