Expose your localhost to Claude and ChatGPT with one line: tapinto.dev

If you’ve ever had to test a local dev site on your phone, or point ChatGPT or Claude at an MCP server you’re still iterating on locally, you know the dance. Spin up ngrok or cloudflared, sign up for an account, copy a random URL, paste it into a config somewhere, hope nothing rotated. For one-off work it’s friction. If you want to point Claude or ChatGPT at something you’re building locally, it’s a wall.

A few months ago I started using tapinto.dev and the dance is gone. The interface is simple: you ask the agent.

One line

In Claude Code or ChatGPT, with the tapinto MCP installed:

“Open a tunnel to localhost:4000.”

That’s it. The agent calls the create_tunnel tool, tapinto provisions a named public HTTPS URL, and you get back something like https://my-thing.tapinto.dev. No browser tab, no account creation flow, no copy-paste from a terminal. The tunnel stays open until you stop it or the session ends.

To install, head to tapinto.dev and follow the install command. After that your agent has the tool available like any other.

Why this is different from ngrok-style tools

Most tunneling tools were built for one use case. You’re a developer, you want to expose a local server so you can test a webhook. Tapinto starts from a different place.

The first difference is that tapinto is MCP-aware. If you tunnel something that is an MCP server, tapinto detects it and exposes the right endpoints in the right shape. ChatGPT’s Developer Mode and Claude’s MCP clients can call it directly. No protocol translation, no manual configuration.

It’s also free without friction. 60 minutes per week, no credit card. For mobile QA on your own site or quick MCP iteration that’s plenty. If you need more, you pay.

Tunnels get readable URLs too. You get https://remarkable-blog.tapinto.dev, not https://e7f9a3.ngrok-free.app. Easier to remember, easier to type on your phone, easier to share with a colleague.

And it’s designed to be called by agents, not just by humans. When the main user is an AI agent the requirements are different. You don’t need a polished CLI or a dashboard. You need a tool definition the agent can call.

Testing this blog on mobile

I’m writing this on the same day I rebuilt this site. To check the layout on my phone, I had Claude Code do:

Open a tunnel to http://127.0.0.1:4000.

Back came https://remarkable-blog.tapinto.dev. Open that URL on my phone, browse around, find the things that look broken at 375px wide, fix them, refresh on the phone. No deploys, no static-site preview services, no copying anything between machines.

When I was done:

Close the tunnel.

That’s the entire workflow. The hard parts of mobile QA (getting your phone to your laptop) collapse into two sentences.

A local MCP server from ChatGPT

The use case I built it for is developing an MCP server. You’re iterating fast, restarting frequently, and the server only exists on your laptop. You want ChatGPT, running in your browser in Developer Mode, to talk to it.

Without tunnels you have two bad options. Deploy on every change, or run ChatGPT against a stale snapshot. With tapinto:

Open an MCP tunnel to my local server on port 8765.

The agent calls the tool, tapinto detects the MCP server, and gives back the public URL plus the registration metadata. You drop the URL into ChatGPT’s MCP configuration once. From that point on, every restart of your local server is invisible to ChatGPT. Same URL, fresh code.

That loop, seconds instead of minutes, is what makes local MCP development actually usable.

Try it

I’ve been using this for a few weeks now. For mobile QA it has saved me enough time that I keep reaching for it. For MCP development it made local iteration actually pleasant. Two minutes to install, and then you forget it’s even there. The agent just handles it.

tapinto.dev has the install instructions and the docs. If you do any work where Claude or ChatGPT needs to see something on your laptop, this is worth trying. Let me know what you build with it.