🌉Free

mcp-remote: connecting stdio-only clients to remote MCP servers

2026-07-30 · ~4 min

Contents

  1. 1.The problem it solves
  2. 2.How you configure it
  3. 3.When you do not need it
  4. 4.What to watch out for

The problem it solves

MCP servers come in two shapes. Local ones run as a process on your machine and talk over stdio — standard input and output. Remote ones are hosted somewhere and speak HTTP. These are different transports, and a client built for one cannot talk to the other.

That becomes a problem when the server you want is remote-only but your client only supports stdio. mcp-remote sits between them: your client launches it as an ordinary local stdio process, and it forwards everything to the remote server over HTTP, translating in both directions.

It also handles the OAuth flow that hosted servers typically require, which is the part that is genuinely awkward to do yourself. On first connection it opens a browser for you to authorize, then keeps the resulting token for subsequent runs.

How you configure it

You do not install mcp-remote as a server in its own right. It goes in the command position of a normal server entry, with the remote server's URL as its argument — so from the client's point of view it is just another local stdio server that happens to be a bridge.

Because it runs through npx, everything in our guide to npx PATH problems applies: if your client cannot find npx, mcp-remote will fail to start with an ENOENT error before it ever reaches the network.

When you do not need it

Check your client's native support first. Claude Desktop, Claude Code, Cursor and VS Code have all added remote server support, and where a client can connect directly, going through a proxy adds a moving part for no benefit. Our detail pages list which transports each server offers, so you can see whether a direct connection is available.

You also do not need it for local servers, which is a surprisingly common mistake. If the server runs on your machine via npx or uvx, it already speaks stdio and there is nothing to bridge.

What to watch out for

A proxy is one more thing that can break, and it fails in ways that are harder to read than a direct connection: an authentication failure at the remote end may surface as a generic startup error locally. When debugging, establish whether the remote server is reachable at all before investigating the bridge.

The stored OAuth token is a credential sitting on your disk. Treat it with the same care as an API key, and revoke it at the provider if you stop using the server.

Latency is added on every tool call, which is usually irrelevant but can matter for chatty tools that make many small requests. If a remote server feels slow through the bridge, that is expected rather than a misconfiguration.