mcp-proxy

What it does

mcp-proxy bridges between MCP transport protocols, primarily converting between stdio and SSE/StreamableHTTP transports. It operates in two modes: it can act as a local proxy that allows stdio-based clients (like Claude Desktop) to communicate with remote MCP servers over SSE, or it can expose a local stdio server over SSE to enable remote clients to access it. This transport bridging is particularly useful when clients and servers support incompatible protocols in a given deployment context.

Who it's for

This server targets infrastructure engineers and teams deploying MCP in cloud or distributed environments. It is useful for anyone bridging Claude Desktop with remote MCP services, exposing local development servers to remote clients, or managing MCP deployments across heterogeneous transport layers.

Common use cases

• Connect Claude Desktop to a remote MCP server that only exposes an SSE endpoint.
• Expose a local development MCP server to remote clients over HTTP.
• Bridge between different MCP transport protocols in a microservices or containerized environment.
• Access remote MCP servers from clients that natively support only stdio transport.
• Deploy MCP servers in cloud environments and proxy them through a local gateway.

Setup pitfalls

• Authentication headers and tokens must be configured correctly for remote servers—use --headers or the API_ACCESS_TOKEN environment variable; OAuth2 requires --client-id, --client-secret, and --token-url.
• When exposing a local stdio server over SSE (mode 2), the --sse-port argument is required; ensure the port is not blocked by firewall or container networking policies.
• Docker deployments must handle port exposure and host networking correctly—local servers accessible to the proxy on localhost may not be reachable inside a container without explicit network configuration.
• The transport type must be explicitly specified if using StreamableHTTP—the default is SSE, so --transport=streamablehttp may be needed for some remote servers.