linux-mcp
# linux-mcp - Linux MCP Server
A Linux system monitoring server built on the [Model Context Protocol (MCP)](https://modelcontextprotocol.io). Provides real-time system information - CPU, memory, disk, network, processes, Docker, and more - via MCP tools over STDIO transport.
[](https://registry.modelcontextprotocol.io) [](https://glama.ai/mcp/servers/Mohabdo21/linux-mcp)

[](https://mcprush.com/to/mohabdo21-linux-mcp?ref=badge)
<p align="center">
<img src="assets/demo.gif" alt="linux-mcp demo" width="100%">
</p>
## Features
- **System** - hostname, OS, kernel, architecture, uptime, load averages
- **CPU** - usage, model, frequency, core counts, temperature sensors
- **Memory** - RAM and swap usage with percentages
- **Disk** - per-partition usage, inodes, mount options, largest files, block devices
- **Network** - interface stats, active connections, listening ports, DNS, ping, IP geolocation & ASN lookup
- **Processes** - running processes sorted by CPU or memory, open file descriptors per process
- **Docker** - containers, images, networks, volumes, disk usage, system info, and container stats
- **Services & automation** - systemd units, service status, user timers, crontab, system cron jobs
- **Security** - active user sessions, failed login detection, SELinux/AppArmor status, firewall/SSH/SUID/world-writable audit with security score
- **Packages** - installed packages and available updates (pacman, dpkg, rpm/dnf, apk)
- **Hardware** - GPU info, PCI/USB bus devices, power/battery analytics
- **Desktop session** - Wayland/X11 protocol, DE identifiers, runtime config
- **Storage health** - RAID status, logrotate configuration, time synchronization, SMART disk health, per-device I/O metrics
- **System health** - comprehensive health assessment with memory, disk, load, and systemd checks
- **/proc diagnostics** - deep /proc inspection: interrupts, softirqs, vmstat, diskstats, filesystems, kernel version, slabinfo
- **Man pages** - system manual pages for any installed command
- **Snapshot** - comprehensive system overview in a single call
- **MCP Resources** - system data also accessible as readable resources
## Prerequisites
- **Go 1.27+** (to build from source)
- **Linux** (the server targets Linux; some tools use Linux-specific paths)
- **Docker** (optional - only needed for Docker tools)
## Installation
### Via MCP Registry
Discover the server on the [MCP Registry](https://registry.modelcontextprotocol.io) and install via your MCP client (VS Code one-click install, or manual config).
### Download pre-built binary
Download the latest binary from the [GitHub Releases](https://github.com/Mohabdo21/linux-mcp/releases) page:
```bash
curl -LO https://github.com/Mohabdo21/linux-mcp/releases/latest/download/linux-mcp
chmod +x linux-mcp
```
A fully static build (no libc dependency) is also available as `linux-mcp_static`.
### Via `go install`
```bash
go install github.com/Mohabdo21/linux-mcp@latest
```
The binary is placed in `$GOPATH/bin/` (typically `~/go/bin/`).
### Build from source
```bash
git clone https://github.com/Mohabdo21/linux-mcp.git
cd linux-mcp
make build
```
The binary is placed at `bin/linux-mcp`.
For a fully static binary (no libc dependency):
```bash
make build-static
```
## Usage
The server communicates over STDIO transport, following the MCP standard. It is designed to be launched by an MCP client (e.g., Claude Desktop, Claude Code, Codex, OpenCode, or any MCP host).
### Running directly
```bash
./bin/linux-mcp
```
This starts the server and listens for MCP requests on STDIN/STDOUT.
### Integration
<details>
<summary><h4>OpenCode</h4></summary>
Add the following to your OpenCode configuration:
```json
{
"mcp": {
"linux-mcp": {
"type": "local",
"command": ["/path/to/linux-mcp"],
"enabled": true
}
}
}
```
</details>
<details>
<summary><h4>Claude Code</h4></summary>
Add the server via the CLI:
```bash
claude mcp add linux-mcp -- /path/to/linux-mcp
```
To scope it to all your projects instead of just the current one:
```bash
claude mcp add linux-mcp --scope user -- /path/to/linux-mcp
```
Or create a `.mcp.json` file in your project root for team-shared configuration:
```json
{
"mcpServers": {
"linux-mcp": {
"type": "stdio",
"command": "/path/to/linux-mcp"
}
}
}
```
Verify the connection inside a Claude Code session with `/mcp`.
</details>
<details>
<summary><h4>Codex</h4></summary>
Add the server via the CLI:
```bash
codex mcp add linux-mcp -- /path/to/linux-mcp
```
Or add it manually to `~/.codex/config.toml` (or `.codex/config.toml` for project-scoped config):
```toml
[mcp_servers.linux-mcp]
command = "/path/to/linux-mcp"
```
Verify the connection with `codex mcp list`.
</details>
### Tools and resources
65 tools and 19 resources covering system, CPU, memory, disk, network, processes, Docker, security, packages, hardware, and more.
**[Full tool and resource reference](docs/tools.md)**
## Configuration
The server can be configured via a JSON file loaded from `~/.config/linux-mcp/config.json` or the `LINUX_MCP_CONFIG` environment variable.
```json
{
"log_level": "info",
"timeouts": {
"get_system_snapshot": "60s",
"ping_host": "5s"
},
"disabled": []
}
```
| Field | Description |
| ----------- | ----------------------------------------------------------------------------- |
| `log_level` | One of `debug`, `info`, `warn`, `error` (default: `info`) |
| `timeouts` | Per-tool timeout overrides as Go duration strings |
| `disabled` | Tool names to disable, including their resource and aggregate collector paths |
Invalid configuration prevents startup. The server also handles **SIGHUP** to reload the configuration file at runtime without restarting; a failed reload retains the last valid configuration. Disabled collectors are skipped by aggregate tools and reported in their errors.
Docker diagnostic responses omit environment values and raw command arguments, including image-history commands. Other diagnostic content, such as logs and labels, can still contain sensitive data; grant access only to trusted clients.
## MCP Registry
Published on the [MCP Registry](https://registry.modelcontextprotocol.io) as `io.github.Mohabdo21/linux-mcp`.
## License
- [MIT](./LICENSE)
## Dependencies
- [modelcontextprotocol/go-sdk](https://github.com/modelcontextprotocol/go-sdk) - MCP SDK for Go
- [shirou/gopsutil/v4](https://github.com/shirou/gopsutil) - System metrics (CPU, memory, disk, network, processes, sensors)
- [docker/go-sdk](https://github.com/docker/go-sdk) - Docker Engine API client
- [moby/moby/client](https://github.com/moby/moby) - Docker client library
- [ip-api.com](https://ip-api.com) - Free IP geolocation API (used by `get_ip_info`)
TDQS
Scored across 65 tools
Descriptions are unusually disciplined: nearly every tool states its scope and explicitly points to the sibling tool for the adjacent case (e.g. get_disk_info vs get_inode_usage, get_process_info vs get_top_io_processes, get_boot_blame vs get_boot_critical_chain vs get_boot_time). A handful of clusters remain genuinely confusable at a glance — get_system_info / get_system_health_check / get_system_snapshot, and get_docker_info vs get_docker_system_info vs get_docker_disk_usage — but the cross-references resolve them for a careful reader.
All snake_case with a verb_noun pattern, and the get_* prefix is used uniformly for the read/inspect family. The only deviations, ping_host and resolve_dns, still follow verb_noun and are clearly the two active network probes. No camelCase or arbitrary verb mixing.
65 tools is well past the point where an agent can hold the surface in mind, and many are single-file readers (get_file_locks, get_shared_memory_segments, get_logrotate_status, four separate boot-analysis tools) that would be better folded into grouped tools. The breadth of Linux diagnostics is real, but the granularity chosen inflates the count far beyond scope.
For a read-only diagnostics server the lifecycle coverage is very broad: CPU, memory, disk/inode/IO, network, processes/FDs/locks, systemd, boot phases, packages, logs/audit, security posture, hardware/GPU, and a full Docker subtree. Gaps are narrow — no arbitrary log/file content retrieval, no filesystem check or SMART self-test control, and no remediation actions at all (consistent with the read-only design, but a limit if the server is meant for administration).