Inspiration

Managing a Linux server still means SSH-ing in and typing commands — or pasting an AI's guesses into the shell. I wanted the middle ground: an AI assistant that can ask the server itself, through tools with a real security model, instead of me copy-pasting docker stats output by hand.

What it does

A Model Context Protocol (MCP) server that exposes eight tools to any MCP-capable AI assistant, so it can answer questions like "which containers are eating the most memory?", "is nginx running?", or "show me the last 50 lines of the syslog" from live server data — no shell, no copy-paste. The eight tools: system_stats (CPU, memory, disk, load average, uptime), docker_ps (running containers), docker_stats (per-container CPU/memory usage), service_status (systemd unit active/enabled state), service_restart (restart a systemd service, write-gated), tail_log (last N lines of a file under /var/log), journal_logs (recent journald entries for a unit), ec2_status (EC2 instances in a region via AWS SDK). The design decision I'm proudest of: write actions are off by default. Ask the server to restart a service and it refuses — set ALLOW_WRITE_ACTIONS=true and the same tool restarts and confirms. The blast radius is yours to grant.

How I built it

Node.js + TypeScript, MCP SDK over stdio. Every command runs through execFile with an argument list — never a shell, so no injection surface. Systemd unit names are validated, log reads are fenced to /var/log, and tool errors set isError=true per the MCP spec. Includes a smoke test (npm run smoke) and one-shot demo caller scripts for repeatable recordings. Docker image included; read-only mode is the recommended default.

Challenges I ran into

The EC2 status check could hang probing IMDS when no AWS credentials were present, so I gave the AWS SDK call a 20-second abort timeout. Parsing df output broke on mount names with spaces, fixed with df -P. The MCP spec detail that tool errors must carry isError=true, verified against an actual service-restart refusal.

Accomplishments that I'm proud of

A security model you can actually trust for a tool that touches production servers: no shell anywhere, validated inputs, fenced log reads, and write actions that refuse unless explicitly opted in. Plus a demo you can re-run byte-for-byte with the scripted caller — all the video beats are npm run one-liners.

What I learned

MCP's spec details matter (like isError on tool results), and the boring robustness work — timeouts, input validation, parse-safe commands — is what makes a demo survive contact with a real machine.

What's next for DevOps MCP Server

Kubernetes pod tools, an allow-list config for which units/logs are readable, and a read-only hosted demo so people can try it without installing anything.

Try it out

npm install && npm run build && npm start

Built With

Share this project:

Updates

Submission history