Built an MCP server? Test it against a real cloud client.
A Streamable HTTP MCP server running on localhost is invisible to Claude.ai, ChatGPT, and anything else that only runs in the cloud — they have no way to reach your machine. Pipehero gives it a public HTTPS URL, the same way it already does for webhooks.
pipehero start myserver --port 3000 # → https://myserver.t.pipehero.app forwards to your local MCP server
Point it at your server's endpoint (usually /mcp) — the full URL is what you paste into the client below.
Known limitations, right now
- SSE doesn't pass through the tunnel yet. Normal request/response calls (
initialize,tools/list,tools/call) work. The optional server-push stream some clients open automatically — a bareGETaccepting onlytext/event-stream— gets an immediate405instead of a silent hang, once the tunnel has--long-requestson (see below). Any response your server streams via SSE still isn't delivered — it's buffered and arrives all at once, or times out if it never closes. - 30-second request timeout by default. A tool call that legitimately runs longer will fail — opt the tunnel into a 120-second timeout instead, from the dashboard (per-tunnel checkbox) or the CLI:
pipehero start myserver --port 3000 --long-requests
Opts the tunnel in once — it's remembered, so you don't need to pass the flag on every run (safe to keep passing it anyway).
If you hit either of these, it's not your server — it's this limitation. We're working on SSE support.
Connect a cloud client
Claude.ai (web)
Settings → Connectors → Add custom connector, then paste your tunnel's URL.
Claude Desktop
Settings → Connectors → Add custom connector, same URL.
ChatGPT
Settings → Connectors → Add a custom connector by URL.
Already running a local client — Claude Code, Claude Desktop, Cursor? It can reach localhost directly; you don't need a tunnel for that. This is specifically for clients that only run in the cloud and have no other path to your machine.
Once it connects, the next question is usually what happens after the demo — versioning the server, packaging it so someone else can run it, keeping a skill or agent config in sync as it changes. That's what Kitbase does — manages, versions and distributes MCP servers, skills and agents.
FAQ
What is this, exactly?
The same tunnel Pipehero uses for webhooks, pointed at a Streamable HTTP MCP server instead. `pipehero start` gives your local server a public HTTPS URL so a cloud-hosted AI client — one that has no other way to reach your machine — can connect to it.
Does this work with stdio MCP servers?
No — stdio servers talk over a local pipe, not HTTP, so there's no tunnel to build for them; they already work with local clients like Claude Code or Claude Desktop directly. This is for Streamable HTTP servers specifically, reached by a client that only runs in the cloud.
Does SSE / streaming work through the tunnel?
Not yet. Regular request/response calls (initialize, tools/list, tools/call) work normally. The optional server-push listen stream some clients open automatically fails fast with a 405 instead of hanging (once the tunnel has --long-requests on); a response your server streams via SSE still isn't delivered incrementally — see Known limitations above.
Is there a request timeout?
Yes, 30 seconds by default. If your tool calls legitimately run longer, opt the tunnel into a 120-second timeout — a checkbox in the dashboard, or `pipehero start myserver --port 3000 --long-requests` from the CLI. It's a per-tunnel setting, remembered after the first time.
How is this different from the MCP webhook tunnel page?
Opposite direction. The webhook tunnel page is Pipehero exposing your captured webhooks to an agent. This page is about exposing your own MCP server to a cloud AI client. If you're trying to let an agent read your webhooks, that's the other page.
Looking to hand your captured webhooks to an agent instead? See the MCP webhook tunnel.
Start debugging webhooks in a minute
Free plan, no credit card. Expose localhost, inspect and replay every webhook.
Get started free