infra-mcp
# infra-mcp
MCP server that gives Claude Code real-time visibility into local infrastructure — Docker containers and system health.
## Tools
### System (8 tools)
| Tool | Description |
|------|-------------|
| `system_overview` | CPU load, memory, uptime |
| `gpu_status` | NVIDIA GPU utilization and VRAM |
| `gpu_processes` | Processes using the GPU |
| `disk_usage` | Filesystem usage |
| `io_pressure` | PSI metrics for I/O pressure |
| `top_processes` | Top processes by CPU/memory |
| `service_status` | systemd service status |
| `memory_detail` | Detailed memory breakdown |
### Docker (7 tools)
| Tool | Description |
|------|-------------|
| `list_containers` | List all containers with status |
| `inspect_container` | Detailed container info |
| `container_logs` | Tail container logs |
| `start_container` | Start a stopped container |
| `stop_container` | Stop a running container |
| `restart_container` | Restart a container |
| `compose_status` | Docker Compose project status |
## Setup
```bash
npm install
```
## Usage
```bash
npm start
```
Configure in Claude Code MCP settings:
```json
{
"mcpServers": {
"infra": {
"command": "node",
"args": ["/path/to/infra-mcp/index.js"]
}
}
}
```
## Configuration
| Env Variable | Default | Description |
|-------------|---------|-------------|
| `DOCKER_HOST` | `/var/run/docker.sock` | Docker socket path |
| `NVIDIA_SMI_PATH` | `nvidia-smi` | Path to nvidia-smi binary |
## Tech Stack
- Node.js (>=18)
- `@modelcontextprotocol/sdk`
- Docker API v1.43 (Unix socket)
- `/proc` filesystem for system metrics
- `nvidia-smi` for GPU monitoring
TDQS
Scored across 21 tools
Most tools have clearly distinct purposes: system monitoring tools target different metrics, and Docker tools separate list/inspect/logs/start/stop/restart. Minor overlap exists between list_containers and compose_status (both list containers but with different grouping) and between container_health and inspect_container (health info is a subset of inspect), but descriptions help differentiate them.
The naming is mixed: system and GPU tools use noun_noun patterns (system_overview, gpu_status, disk_usage), while Docker tools use verb_noun patterns (list_containers, start_container, restart_container). This inconsistency is mildly confusing, though the pattern is predictable within each subdomain, and all names are readable.
21 tools is on the higher end of the optimal range, but each tool covers a specific monitoring or Docker management function that justifies its presence. The count is appropriate for a server that spans both system health and container operations, without feeling bloated.
The server covers system monitoring and Docker container lifecycle well, but has notable gaps: no service management (only status), no Docker container create/remove, no image pull/remove, and no volume/network creation. Basic operations are covered, but full infrastructure management is incomplete.