Run a local MCP server (stdio) remotely – options, effort and risks

Most MCP servers on GitHub and npm start with a command like npx -y @someone/mcp-server. They communicate over stdio: the AI app starts the server as a process on your computer and talks to it via standard input and output. That works in Claude Desktop, Claude Code or Cursor – but not in Claude on the web, not on your phone and not for your colleagues. This guide explains why, and what your options are.

Why stdio only works locally

A stdio server has no network address. It only exists while a program on the same computer runs it. Claude on the web and the mobile app, however, connect to your server from Anthropic's cloud – and need a public HTTPS address that speaks Streamable HTTP. On top of that: when your laptop sleeps, the server is gone too.

To use a stdio server remotely, you need four things:

1. A bridge from stdio to Streamable HTTP.
2. A server that runs around the clock, with a TLS certificate and its own address.
3. Authentication, so that not everyone on the internet can call your tools – ideally OAuth, because Claude connectors support it directly.
4. Operations: restart after crashes, updates, logs, safe storage of credentials.

Option 1: Run it yourself with a bridge

There are open-source bridges that start a stdio server and expose it over HTTP:

• Supergateway (MIT license, Node.js) can expose a stdio server as Streamable HTTP.
• mcp-proxy by sparfenyuk (MIT license, Python) exposes stdio servers over HTTP; check its documentation for which transports your version offers in server mode.

An example with Supergateway:

npx -y supergateway \
  --stdio "npx -y @modelcontextprotocol/server-filesystem ./folder" \
  --outputTransport streamableHttp \
  --port 8000

The server is then reachable at http://localhost:8000/mcp. For Claude, several things are still missing: a reverse proxy such as Caddy or nginx with a TLS certificate and your own domain, a process manager (systemd or Docker with a restart policy) and, above all, authentication. The bridges themselves don't include OAuth. Claude now accepts fixed keys as "Request headers", but then all users share the same key.

Pros: full control, no extra cost beyond the server.

Cons: you are responsible for security, updates and availability. Implementing OAuth yourself is the hardest part.

Option 2: A tunnel to your own computer

Tunnel services give a port on your computer a public address. Together with a bridge, your local server is reachable within minutes.

Pros: fast, good for trying things out.

Cons: the server only runs while your computer is on. The tunnel provider relays the traffic – check where it is based and whether that fits your data protection requirements. Not a solution for continuous use or a team.

Option 3: Rebuild the server for Streamable HTTP

If you control the server code, you can add Streamable HTTP directly. The official MCP SDKs (for example for TypeScript and Python) include ready-made building blocks. You no longer need a bridge, but hosting, TLS and authentication remain your job.

Option 4: A hosting service

Several providers host MCP servers and take care of address, sign-in and operations. When choosing, look at:

• Where data and data centers are, and whether a data processing agreement (DPA) is available.
• Isolation: does each server run separately, or do servers share file system and network?
• Credential handling: stored encrypted, never in logs.
• Sign-in: OAuth per person, or just one shared key?
• Idle cost: does the server sleep when unused, and how fast does it wake up?

Security: stdio servers are built for your own machine

Many stdio servers assume that only you use them. A file system server with access to your home folder is handy locally – on the internet it would be a wide-open door. Before offering a server remotely:

• Give it only the data and permissions it really needs.
• Run it isolated, for example in its own container without access to other services.
• Limit outgoing connections to the destinations the server needs.
• Read the tool descriptions: they are shown to the model and can contain hidden instructions.
• Store credentials encrypted, never in code or logs.

How XenMCP will solve this

XenMCP (by Xenaxio) is an MCP hosting service in Germany, currently in preparation. Planned for after the beta launch: you point to an npm package, a Docker image or a GitHub repository, XenMCP wraps the stdio server with a bridge, starts it in its own sandbox (gVisor) with limited network access and encrypted credentials, and gives you an address https://<name>.xenmcp.com/mcp with OAuth 2.1. At beta launch, there will first be ready-made servers for MongoDB, PostgreSQL and MySQL/MariaDB. Read more about security – or go straight to the waitlist.

How to add a finished address to Claude is shown in Connect an MCP server to Claude.

FAQ

Can I add a stdio server directly to Claude on the web?

No. Claude on the web and on your phone needs a public HTTPS address with Streamable HTTP. A stdio server has to be brought online via a bridge and a server first.

Is a tunnel enough for continuous use?

Not really. The server is only reachable while your computer runs, and the tunnel provider sees the traffic. For trying things out, a tunnel is fine.

Do bridges like Supergateway include authentication?

No, they only translate the protocol. Authentication, TLS and operations are up to you or a hosting service.

Do Python servers work too?

Yes, the bridge starts any command, including uvx or python. What matters is that the server speaks stdio.