Runs a SonarQube scan for a project using sonar-scanner-cli and the configured SonarQube server, requiring a sonar-project.properties file in the project.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@devbox-mcp run the test suite for the 'my-app' project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that lets an LLM run a project's real test suite, and a SonarQube scan, against projects it can see on disk — without giving the LLM a raw shell.
Tools:
list_projects — lists directories under PROJECTS_ROOT, detected
toolchain (dotnet / npm / pytest / none).
run_tests(project) — runs that project's test suite in a throwaway,
one-shot container: the repo is bind-mounted read-only, a tmpfs
provides writable scratch space, and the container is removed after.
project must be a name list_projects returned — this is the only
guard against a path-traversal or prompt-injected argument escaping
PROJECTS_ROOT.
sonar_scan(project) — runs sonar-scanner-cli against the project
(requires a sonar-project.properties file in it) and your SonarQube
server.
run_tests and sonar_scan need to launch containers, which normally means
mounting /var/run/docker.sock. Don't do that. A mounted Docker socket
is root on the host — anyone who can make this server run an arbitrary
command (a malicious test file, a prompt-injected tool argument) can then
talk to the Docker API directly and do anything root can do.
Put tecnativa/docker-socket-proxy
in front of the real socket instead, and point this server's DOCKER_HOST
at the proxy. Scope the proxy to only what's needed:
environment:
CONTAINERS: 1 # create/start/wait/logs/remove containers
POST: 1 # without this, the proxy is read-only
IMAGES: 1 # pull the toolchain images
# everything else defaults to 0/off: no EXEC, no NETWORKS, no VOLUMES,
# no access to containers this server didn't create.This is a real narrowing (no docker exec into unrelated containers, no
host-network access, no volume mounts beyond what this server's own docker run calls specify), not a sandbox: a compromised instance can still launch
containers on your host. Treat it accordingly — this is not something to
expose beyond a private network.
Related MCP server: Docker MCP Server
Env var | Default | Meaning |
|
| Directory of project checkouts to operate on |
| (docker default) | Point at your docker-socket-proxy, e.g. |
| — | Your SonarQube server, reachable by address, not by a Docker Compose service name — the scan runs in its own one-shot container on the default bridge network, not your SonarQube stack's network |
| — | SonarQube user/analysis token |
|
| Kill switch per container run |
|
| HTTP port (Streamable HTTP MCP transport, path |
docker run -p 8000:8000 \
-e PROJECTS_ROOT=/repos \
-e DOCKER_HOST=tcp://docker-socket-proxy:2375 \
-e SONAR_HOST_URL=http://your-sonarqube:9000 \
-e SONAR_TOKEN=... \
-v /path/to/your/repos:/repos:ro \
ghcr.io/egoushka/devbox-mcp:latestPin an exact tag/digest in production — latest is for trying it out.
No arbitrary path execution (only list_projects-returned names), no write
access to the mounted repos, no auto-remediation, no CI trigger integration.
Toolchains supported: dotnet, npm, pytest — pull requests welcome for more.
MIT
This server cannot be deployed
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Run verified read-only code tools: quant diagnostics + agent-ops preflight, no source exposure.
Remote Linux boxes for coding agents: Docker, a browser, screenshots, logs, human takeover.
Change-aware CI validation and affected-test guidance for coding agents.
