What it does
mcp-proxy bridges MCP clients and servers across incompatible transport protocols. It operates in two modes: in the first, it acts as a stdio server that proxies requests to a remote SSE or StreamableHTTP server, enabling clients like Claude Desktop to reach remote servers that don't support stdio natively. In the second mode, it exposes a local stdio server as an HTTP SSE endpoint, making it accessible to remote HTTP clients. Both modes support OAuth2 and custom header authentication, and the stdio-to-HTTP mode lets you pass environment variables and command-line arguments to spawned local servers.
Who it's for
Backend engineers wiring Claude Desktop to remote MCP servers that only offer SSE endpoints; DevOps teams exposing locally-running stdio servers to remote clients over HTTP; anyone building networked MCP deployments where transport protocols don't match between client and server.
Common use cases
- Connect Claude Desktop to a remote SSE-only MCP server via stdio proxy
- Expose a local stdio MCP server as an HTTP SSE endpoint for remote clients
- Add OAuth2 or bearer-token authentication to remote MCP servers
- Run multiple local stdio servers behind a single HTTP proxy in Docker or Kubernetes
- Gateway a local MCP server to multiple remote clients
Setup pitfalls
- Spawning local stdio servers requires filesystem and process execution access—sandbox the proxy's working directory and validate commands
- Requires explicit transport protocol selection (
--transport=streamablehttpfor non-SSE) or clients will fail with protocol errors - OAuth2 authentication needs all three parameters (
--client-id,--client-secret,--token-url); partial config fails silently - SSE endpoint listens on a network port—place behind a reverse proxy or firewall to prevent public access