use_toolLABSCO SUMMARY
It buys tool-slot headroom, and costs you a discovery hop.
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.
What it is
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.
What you get
use_tool— routes one call to a named backend, takingbackend_server,server_toolandtool_argumentsdiscover_backend_tools— lists the available backends and their tools, optionally narrowed to one backend- Backends declared in a
config.jsonwhere 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.envfile rather than in the config itself - Automatic process management: backends are started, kept alive and cleaned up by the gateway
Requirements
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.
Setup effort
Run a container — build the image from the repository, then point your client at it
USE CASES
01
Adding a large server without evicting the others
Put the tool-heavy server behind the gateway so it costs two client slots instead of dozens.
02
Finding out what a backend can do
Ask the gateway to enumerate a specific backend's tools before routing a call to one of them.
03
Running many servers from one client entry
Declare each backend in the config and reach all of them through a single MCP entry, with the gateway managing their processes.
04
Keeping tokens out of your client config
Reference credentials as ${VAR_NAME} in the backend config and supply them through an env file at container start.
2 tools
Listed in project docs. Your client may show a different list.
discover_backend_toolsBEFORE YOU INSTALL
What to know first
Tools you get
2 tools named in the project's documentation.
Requires
docker on PATH
INSTALLATION
Connect your client
MCP Clients
Any MCP client
Clone the repository and build the image
ANY MCP CLIENT · TERMINAL
git clone https://github.com/delexw/mcpware.git
cd mcpware
docker build -t mcpware . --no-cache
cp env.example .envDeclare your backends, then add this to your client config
Edit config.json in the clone: under "backends", give each server a command, args and optional env, and reference secrets as ${VAR_NAME} with the values in .env (config.example.json has more examples). <YOUR_PATH_TO_MCPWARE> is the absolute path to your clone. The Docker socket mount is only needed when a backend itself runs as a Docker container.
ANY MCP CLIENT · JSON
{
"mcpServers": {
"mcpware": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-v",
"<YOUR_PATH_TO_MCPWARE>/config.json:/app/config.json:ro",
"-v",
"/var/run/docker.sock:/var/run/docker.sock",
"--env-file",
"<YOUR_PATH_TO_MCPWARE>/.env",
"mcpware"
]
}
}
}
