DEV Community

Cover image for linux-mcp - My agent kept running terminal commands, so I built this
Mohannad Abdulaziz
Mohannad Abdulaziz

Posted on

linux-mcp - My agent kept running terminal commands, so I built this

#linux #mcp #devops #go

linux-mcp

I was debugging a config issue on my server and chatting with OpenCode to help. Every time it needed to check system state - memory usage, disk space, running processes - it would chain together a long pipeline of terminal commands. ps aux | grep ... | awk ..., df -h | grep ..., you know the drill.

It would work, fail, try a different pipeline, fail again, retry. What should have been a one-line answer turned into ten minutes of trial and error.

That's when it clicked: the agent doesn't need better shell scripting. It needs a tool that already knows what to ask and how to parse the answer.

So I built linux-mcp - an MCP server that gives AI agents direct, structured access to Linux system data. 40+ tools covering CPU, memory, disk, network, processes, Docker, systemd, GPU, security, and more.

What it does

Instead of the agent running free -m | grep Mem | awk '{print $3/$2 * 100}', it calls get_memory_info and gets this back:

{
  "total_mb": 16384,
  "used_mb": 12288,
  "percent": 75.0,
  "swap_total_mb": 4096,
  "swap_used_mb": 1024
}
Enter fullscreen mode Exit fullscreen mode

No parsing, no retries, no "oops, wrong flag."

Tool What it returns
get_system_snapshot Everything in one call
get_cpu_info Usage, model, frequency, cores
get_memory_info RAM and swap stats
get_disk_info Per-partition usage, inodes, mount options
get_network_connections TCP/UDP connections with process info
get_docker_container_stats Live CPU/memory/network per container
get_gpu_info NVIDIA/AMD/Intel - usage, temp, power
get_failed_logins Brute force detection
get_man_page Any man page, any command
get_listening_ports Ports and their processes

Full list: 40+ tools + MCP resources.

Setup 

{
  "mcp": {
    "linux-mcp": {
      "type": "local",
      "command": ["/path/to/linux-mcp"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Build from source 

git clone https://github.com/Mohabdo21/linux-mcp.git
cd linux-mcp
make build
Enter fullscreen mode Exit fullscreen mode

Pre-built binary 

curl -LO https://github.com/Mohabdo21/linux-mcp/releases/latest/download/linux-mcp
chmod +x linux-mcp
Enter fullscreen mode Exit fullscreen mode

Static binary available (no libc dependency).

Design

  • Written in Go using the official MCP Go SDK
  • STDIO transport - zero networking config
  • Per-tool configurable timeouts
  • SIGHUP config reload - no restart needed
  • Docker tools optional - only activate if Docker is installed

Links

Top comments (1)

Collapse
 
mads_hansen_27b33ebfee4c9 profile image
Mads Hansen •

The "agent does not need better shell scripting" point is exactly right.

Shell access is powerful, but it is a terrible interface for repeated operational questions. The model has to remember flags, parse unstable text, handle distro differences, and decide when a command is safe. A structured tool turns that into a narrower contract:

  • named operation
  • typed inputs
  • predictable output shape
  • timeout boundary
  • clearer permission model
  • better logs for what the agent actually asked

That matters even more when the tool touches production systems. A server diagnostics tool and a database diagnostics tool have the same core problem: the useful path should be easier than improvising arbitrary commands.

Related angle on keeping the tool surface allowlisted: https://conexor.io/blog/mcp-database-tool-allowlists?utm_source=devto&utm_medium=comment&utm_campaign=engagement

The more MCP servers move from demos into ops workflows, the more this kind of boring structure will matter.