What it does

mcp-proxy bridges incompatible MCP transports, enabling clients to communicate across protocol boundaries. In its primary mode, it acts as a gateway between Claude Desktop (which uses stdio) and remote MCP servers exposing Server-Sent Events (SSE) or Streamable HTTP endpoints—protocols otherwise unsupported in Claude's native client. In reverse mode, it exposes a local stdio-based MCP server over SSE, making it remotely accessible to other clients. The proxy transparently converts between transport protocols without modifying underlying MCP semantics.

Who it's for

Infrastructure engineers bridging legacy or specialized MCP servers into Claude Desktop workflows, and teams running local MCP servers that need remote-client access without native protocol support. Also useful for developers integrating Claude with custom MCP implementations that don't conform to stdio defaults.

Common use cases

• Connect Claude Desktop to remote MCP servers using SSE endpoints not natively supported by the client
• Expose a local stdio MCP server over SSE for consumption by remote LLM clients
• Enable OAuth2-authenticated access to protected MCP endpoints
• Bridge Streamable HTTP servers into stdio-based tooling pipelines

Setup pitfalls

• OAuth2 configurations (client ID, secret, token URL) must match the remote server's auth scheme; missing or misconfigured credentials fail silently without helpful error messages
• Transport selection (--transport=streamablehttp vs --transport=sse) must match the remote server's actual protocol; mismatches manifest as cryptic connection errors
• When exposing servers via SSE mode, --sse-host binding must be correct for your network topology (localhost vs 0.0.0.0 vs specific IP); incorrect binding silences the server without clear diagnostics
• The proxy requires filesystem read access for configuration files; ensure the process has adequate permissions