mcp-stdio-bridge

The mcp-stdio-bridge project provides a tiny runtime image that keeps stdio-only MCP tools alive and exposes them over HTTP/SSE via mcp-proxy. This allows you to run stdio-based MCP servers (which typically run in a local or CI environment) inside a container and bridge their output to a stable HTTP/SSE endpoint. The setup is particularly handy when deploying to Kubernetes, where you can enable the stdio bridge per server and have the bridge forward requests to tools like npx chrome-devtools-mcp or uvx-based servers.

To use it, start the container with mcp-proxy and point it at the desired stdio tool. For example, you can launch an MCP server using npx chrome-devtools-mcp and expose it on port 3000 via SSE. The bridge downloads the tool on first start and keeps it alive, forwarding any arguments after the -- separator to the stdio server. You can also use uvx to run uv-compatible MCP servers, or other supported stdio tools, by adjusting the command and arguments accordingly.

Prerequisites:

• Docker installed on your machine (or Kubernetes for deployment)
• Internet access to download tools via npm/uv when the container starts

Installation steps:

1. Pull the MCP stdio bridge image: docker pull ghcr.io/icoretech/mcp-stdio-bridge:latest

2. Run a local example exposing an HTTP/SSE endpoint on port 3000 and launching an stdio MCP server (e.g., chrome-devtools-mcp): docker run --rm -p 3000:3000
   ghcr.io/icoretech/mcp-stdio-bridge:latest
   mcp-proxy --port 3000 -- npx chrome-devtools-mcp

3. Alternatively, use uvx to run Python-based or other stdio tools inside the container: docker run --rm ghcr.io/icoretech/mcp-stdio-bridge:latest
   uvx mcp-server-reddit

4. For Kubernetes, configure a stdioBridge bridge block in the mcp-server Helm chart, enabling the bridge per server and pointing to the image/tag you want to use. See the README for sample YAML.

Prerelease notes:

• The image includes multi-arch support (amd64 and arm64).
• The first run downloads the selected stdio tool (e.g., npx chrome-devtools-mcp) and caches it inside the container.

Tips and caveats:

• The bridge forwards any arguments after -- to the stdio tool. Use this to pass specific flags to the underlying MCP server.
• If you need multiple stdio targets, use the --named-server option of mcp-proxy or run separate bridge instances for each target.
• If you rely on environment variables (e.g., API keys), enable passEnvironment in the Kubernetes Helm chart so those vars are forwarded to the child process.
• The image can be used both as a stand-alone container for local testing and as part of a Kubernetes deployment behind a service or Ingress for SSE endpoints.
• Check the release notes for tag changes (e.g., 0.3.1) to ensure compatibility with your tooling.