Two AI surfaces on my work laptop, Claude Desktop and VS Code, currently reach eighteen connected tools, including filesystem, fetch, memory, and WolframAlpha, through a single MCP gateway. None of that requires a single open port on the Windows host. That constraint, not the tool count, is the actual design decision worth explaining.
Working across more than a hundred SAP systems for a client means most of what I touch during the day is not mine to experiment on. Testing an AI agentic workflow, a new MCP tool, or a CI/CD pipeline idea needs a place that is genuinely separate from anything client facing, disposable if it breaks, and still realistic enough to be useful, meaning a real git server and a real pipeline runner, not a toy.
The host is Windows 11 Pro. Two things run directly on it: Docker Desktop, with its MCP Toolkit enabled under a dedicated claude_dev profile, and Claude Desktop itself, authenticated through enterprise single sign on. The MCP Toolkit is the bridge: it exposes Filesystem, Fetch, Memory, and WolframAlpha as tools that both Claude Desktop and VS Code can call.
Everything else lives one layer down, inside WSL2 running Ubuntu 24.04, with Docker Engine installed natively there rather than only through Docker Desktop integration. Four containers sit together on a single Docker bridge network, reaching each other by service name:
The detail that matters most: none of the four containers publish a port to the Windows host. They only reach each other across the shared bridge network. The only thing exposed outward is the Portainer dashboard port, for my own use.
Day to day, this means a full loop: write code in claude-code-dev, push it to gitlab-ce, watch gitlab-runner execute the pipeline defined in a committed configuration file, and check the result in Portainer, all without a single request leaving the WSL2 network boundary. A real climate data pipeline and this website project itself have both been developed and tested inside exactly this sandbox before anything client facing was touched.
This is a personal learning environment, run in my own time and kept deliberately apart from any client system or client data. It exists so I can try a new tool, a new workflow, or a new idea safely, before ever considering whether it belongs anywhere near actual project work. The isolation described above, one bridge network with nothing exposed to the host, is not just a technical choice. It is the boundary that makes it safe to experiment freely in the first place.
The value here was never the tool count. It was designing the boundary first, a single bridge network with nothing exposed to the host, and only then filling it with whatever tools the work actually needed.