The trade is explicit: two slots in the client instead of fifty, at the price of the model having to discover backend tools before calling them. That is worth it precisely when you are over the limit — a GitHub server alone can bring 50+ tools. It is also designed to sit alongside your other servers rather than replace them, so the ones you use constantly can stay wired directly while the long tail goes behind the gateway. Note that when mcpware runs in Docker, backends using local commands like `npx` execute inside its container, not on your host.
A routing gateway. MCP clients often cap how many tools can be loaded at once; mcpware presents only two tools to the client and forwards calls to whichever backend server actually owns them. It runs as a Docker container, launches and manages the backend processes itself, and hosts several servers at once behind a single entry.
- `use_tool` — routes one call to a named backend, taking `backend_server`, `server_tool` and `tool_arguments`
- `discover_backend_tools` — lists the available backends and their tools, optionally narrowed to one backend
- Backends declared in a `config.json` where each entry names any command — `docker`, `npx`, `node`, `python` — with its own args, env and timeout
- Environment substitution in that config through `${VAR_NAME}`, so tokens stay in a `.env` file rather than in the config itself
- Automatic process management: backends are started, kept alive and cleaned up by the gateway
Docker, plus a clone to build the image (`docker build -t mcpware .`). The client runs it as a `docker run` with your `config.json` mounted read-only and an `--env-file` for the backend credentials. If any backend is itself a Docker image, the Docker socket must be mounted — `/var/run/docker.sock` on Linux, macOS and WSL2, `//./pipe/docker_engine` for native Windows containers — otherwise mcpware cannot start it and fails with permission errors. Python 3.10+ for local development. MIT licensed.