This is plumbing rather than a capability of its own. Its value is in the transports and the config watcher: container-based servers mean the host needs no language toolchains installed, and editing the config adds or removes a server live rather than at the next restart. Note that it speaks HTTP to its clients, so it fits a service architecture rather than an editor expecting a stdio server.
A Go service that connects to multiple MCP servers and exposes their tools through one HTTP API. It reads the same server-configuration format your editor already uses, and supports local processes, remote HTTP servers and containerised ones.
- A single tool listing across every connected server, with each entry tagged by which server it came from
- One execution endpoint: name the server, the tool and the arguments
- A listing of which servers are currently connected, and a stream of registry updates for clients that want to react to changes
- Three ways to reach a server — a local process over standard input and output, a remote HTTP endpoint, or a container image — so the host does not need every language runtime installed
- Configuration is the familiar server map used by common editors, with environment placeholders expanded when it loads
- The configuration file is watched: adding, removing or changing a server starts, stops or reloads it without a restart, and an invalid edit is rejected rather than applied
The compiled binary, built with a Go toolchain, or one of the published container images. A configuration file listing the servers to aggregate; the listen address is configurable. Running containerised servers needs access to a container runtime on the host.
One command — npx -y @modelcontextprotocol/server-github