The bridge is the front door to whatever it launches, so the settings that matter are the ones bounding it: `allowed_origins` decides who may connect, the connection limit decides how many at once, and the size caps stop a large response from becoming a problem. Restart behaviour backs off from 1s up to 60s, which matters if a wrapped server is crash-looping.
A Go bridge that wraps subprocess MCP servers with HTTP streaming, so a web client can talk to servers that only speak stdio. Each wrapped server gets its own namespace in the URL, and the bridge manages the process behind it.
- An SSE stream per namespace and a POST endpoint for requests — `GET /mcp/{namespace}` and `POST /mcp/{namespace}/message`
- Subprocess management: spawning on demand, connection reuse, graceful shutdown on SIGTERM and SIGINT, and restarts with exponential backoff
- The MCP methods handled at the bridge — `initialize`, `tools/list`, `tools/call` and `ping`
- Health per bridge and per namespace — `/health` and `/health/{namespace}`
- Prometheus metrics at `/metrics`, including `mcp_http_requests_total`, `mcp_tool_calls_total`, `mcp_tool_errors_total` and `mcp_active_sessions`
- A live debug view — `/debug` for the dashboard and `/debug/stream` for the message log as SSE
- Limits you set rather than discover: request and response size caps, a connection limit, request and idle timeouts, and an origin allowlist
A Go toolchain and `make build`, then run `./bin/bridge --config config.yaml`. The YAML has two halves: a `bridge` block with the port, allowed origins, timeouts and limits, and a `servers` block naming each wrapped server with its binary, args, env, timeout, max restarts and whether to auto-start. Nothing to authorize at the bridge itself — credentials belong to the servers it launches, passed through their `env` entries.
One command — npx -y test-mcp-server