LABSCO SUMMARY
It solves the transport mismatch in both directions, which is rarer than it sounds.
Most bridges only go one way — remote server to local stdio client. Being able to run it the other way, publishing a local stdio server on a port, is what makes it useful for sharing one server with a team or reaching it from a container. The OAuth handling is the other quiet win: token refresh happens in the proxy rather than in each client, and reset is the documented escape hatch when a cached login goes bad.
What it is
A bidirectional MCP proxy. In remote-client mode it connects to a remote MCP server and presents it locally over stdio, so a client that only speaks stdio can use a hosted server. In local-server mode it launches your stdio server as a subprocess and publishes it as an SSE or Streamable HTTP endpoint. Transport is detected from the URL and can be overridden.
What you get
- A remote server presented to a stdio-only client, with the transport chosen automatically — URLs containing
/sseuse SSE, everything else uses Streamable HTTP, and--transportforces either - A local stdio server published over the network with
--port, in SSE or, with--transport streamable-http, Streamable HTTP - The full OAuth flow with automatic token refresh, and
mcp-proxy resetto clear stored auth when a login goes wrong - Environment variables injected into the proxied server with
-e KEY VALUE, or the whole environment passed through with--pass-environment - Custom headers added on the client side with
-H, and a bind host chosen with--host, which defaults to127.0.0.1 - Log verbosity controlled through
RUST_LOG, since the upstream crate is noisy by default - A Rust library surface —
run_sse_clientandrun_streamable_http_clientwith their config structs — for embedding the same behaviour
Requirements
No account and no key for the proxy itself; whatever the server behind it requires still applies. Install with cargo install rmcp-proxy, or cargo install --git https://github.com/stephenlacy/mcp-proxy, or build with cargo build --release. In client mode the command is mcp-proxy <url>; in server mode it is mcp-proxy --port <port> -- <your command and args>. Auth data is cached under ~/.mcp-auth, which mcp-proxy reset clears.
Setup effort
One command — cargo install rmcp-proxy
USE CASES
Using a hosted MCP server from a stdio-only client
Point the proxy at the remote URL and register the proxy itself as the client's command; transport detection handles SSE versus Streamable HTTP.
Sharing a local server over the network
Launch your stdio server through the proxy on a port so other machines or containers can reach it, choosing SSE or Streamable HTTP.
Getting past an OAuth server your client cannot handle
Let the proxy run the full flow and refresh tokens, and clear the cache with the reset command when a login gets stuck.
Keeping secrets out of a server's own config
Inject the environment variables at proxy launch with -e, or pass the whole environment through, rather than writing them into the client config.
BEFORE YOU INSTALL
What to know first
Requires
mcp-proxy on PATH
INSTALLATION
Connect your client
Add the block to your client, or run the command directly.
Server setup
Configuration file
{
"mcpServers": {
"my-remote-server": {
"command": "mcp-proxy",
"args": [
"<YOUR_SERVER_URL>/mcp/instances_abc123"
]
},
"sse-server": {
"command": "mcp-proxy",
"args": [
"--transport",
"sse",
"<YOUR_SERVER_URL>/sse"
]
}
}
}<YOUR_SERVER_URL>/mcp/instances_abc123 and <YOUR_SERVER_URL>/sse are the addresses of the remote MCP servers you want to reach. Keep only the entries you need. Each entry runs the mcp-proxy command that cargo install rmcp-proxy puts on your PATH
cargo
cargo install rmcp-proxy