Hello Rhevin!
Nice project and it would be a good addon for OrbStack. I just switched from Docker Desktop to Orbstack and found your mcp. What is really missing would be a more sandbox like approach, so we could shield the other containers from a over enthusiastic agent. Something to limit a e.g. STDIO mcp server to a certain orbstack stack. This would allow full control over this stack for a Agent which has access to this mcp (given via project based mcp add on parameterr) without allowing the agent to access other containers.
I attach my agents output
Cheers - Tom
Orbstack MCP inspection:
The implementation is much riskier than the README suggests. Every tool builds a shell string and runs it with shell=True; many of those strings contain model-supplied names, paths, commands, and even an unrestricted extra_args field. That turns ordinary “inspect” calls into possible arbitrary command execution on the Mac. It also exposes forced deletion/pruning and Kubernetes apply operations without an internal confirmation layer. I would not install this version as-is.
One more important point: this is not actually bound to OrbStack. It invokes plain docker and plain kubectl, so it follows whatever Docker and Kubernetes contexts happen to be active; the Kubernetes “apply” tool could therefore target a completely different reachable cluster. OrbStack already makes its engine available through the normal docker/Compose CLI, so the MCP mostly adds a thin—and currently unsafe—schema layer.
Other significant concerns:
- It exposes forced deletion and mutation: Docker prune/remove, Compose down with volumes, VM deletion with -f, arbitrary container/VM commands, image pulls, and Kubernetes apply. server.py Docker prune, server.py VM operations
- It is not actually constrained to OrbStack. Plain docker and kubectl follow the current Docker and Kubernetes contexts, so the tools could affect another local or remote engine/cluster.
- docker_run permits arbitrary host volume paths and unrestricted extra_args; docker_exec and orb_run accept arbitrary commands. server.py lines 50–88
- The source registers 33 tools: 22 generic Docker/Compose wrappers, four generic Kubernetes wrappers, and only seven OrbStack-specific tools. It is essentially a thin shell wrapper, not an OrbStack API integration.
- The project is early-stage: no releases or tags, no behavioral/security tests, only lint CI, and the sole dependency is unpinned as mcp>=1.2.0. The README also has an invalid UV configuration example and disagrees with the actual license. Repository, requirements
Hello Rhevin!
Nice project and it would be a good addon for OrbStack. I just switched from Docker Desktop to Orbstack and found your mcp. What is really missing would be a more sandbox like approach, so we could shield the other containers from a over enthusiastic agent. Something to limit a e.g. STDIO mcp server to a certain orbstack stack. This would allow full control over this stack for a Agent which has access to this mcp (given via project based mcp add on parameterr) without allowing the agent to access other containers.
I attach my agents output
Cheers - Tom
Orbstack MCP inspection:
The implementation is much riskier than the README suggests. Every tool builds a shell string and runs it with shell=True; many of those strings contain model-supplied names, paths, commands, and even an unrestricted extra_args field. That turns ordinary “inspect” calls into possible arbitrary command execution on the Mac. It also exposes forced deletion/pruning and Kubernetes apply operations without an internal confirmation layer. I would not install this version as-is.
One more important point: this is not actually bound to OrbStack. It invokes plain docker and plain kubectl, so it follows whatever Docker and Kubernetes contexts happen to be active; the Kubernetes “apply” tool could therefore target a completely different reachable cluster. OrbStack already makes its engine available through the normal docker/Compose CLI, so the MCP mostly adds a thin—and currently unsafe—schema layer.
Other significant concerns: