The interesting move is turning a launch command into a URL. That makes a stdio server usable from a client on a machine with no Node, no Python and no Docker, and it makes one container the single place where those runtimes are installed and updated. The other side of that: anything you proxy runs in the container with the container's filesystem and network, so what you point it at matters as much as what you install.
A streamable HTTP MCP server that proxies to stdio MCP servers. It exists for one problem the other proxies leave alone: the stdio server you want needs a command your machine does not have. xMCP runs inside a container with the common launchers preinstalled, so you address the target server by URL instead of by local command.
- A stdio MCP server addressed as a URL: the name, the command and its arguments become query parameters, for example `?name=context7&command=npx&args=-y,@upstash/context7-mcp`
- Launchers already present in the container so nothing has to be installed on your own machine — `npx`, `bunx`, `uv` and `docker`
- Room to extend: add whatever else you need to the container image, and the same URL form works for it
- A local MCP Inspector alongside the server for checking what the proxied session exposes
No account and no key. Docker: `docker compose up -d`, or `make start`. The server listens at `http://localhost:3001/mcp`, and the Inspector at `http://localhost:6274` — the Inspector needs an auth token in the URL, which `make logs` prints. The npm package name is `xmcp-server` (1.0.0).
One command — npx -y @upstash/context7-mcp