DevOps Dashboard MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| service_statusA | Check the status of a systemd service. Shows whether it's active/inactive/failed, its enabled state, PID, memory usage, and recent log lines from systemctl status output. |
| service_logsA | Fetch recent journal logs for a systemd service. Supports filtering by time range, priority level, and grep patterns. Useful for debugging service issues and monitoring application output. |
| process_listA | List running processes with CPU, memory, and runtime details. Sort by CPU or memory to find resource hogs. Filter by process name to find specific applications. |
| disk_usageA | Show disk space usage by filesystem/mount point. Includes both space and inode usage. Excludes virtual filesystems (tmpfs, devtmpfs) for clarity. Essential for preventing disk-full outages. |
| memory_infoA | Show RAM and swap usage. In detailed mode, includes buffer/cache breakdown from /proc/meminfo. Also reports system load averages for context. |
| port_scanA | List all listening TCP/UDP ports with their associated processes. Can filter to a specific port number or protocol. Uses 'ss' (modern) with 'netstat' fallback. Useful for checking what services are exposed. |
| cron_listA | List cron jobs for the current user, a specific user, or all users. Also shows system cron files from /etc/crontab and /etc/cron.d/. Includes cron.daily, cron.weekly, and cron.monthly summaries. |
| nginx_configA | Read, validate, and inspect nginx configuration. Actions: 'show' reads the main config or a specific site, 'test' runs nginx -t validation, 'list_sites' shows enabled/available sites, 'full_config' dumps the fully resolved configuration. |
| docker_statusA | Inspect Docker containers, images, networks, volumes, and resource usage. Gracefully reports if Docker is not installed or the daemon is stopped. The 'overview' action gives a quick summary; 'stats' shows live CPU/memory per container. |
| system_healthA | Run an aggregate health check across the entire system. Checks load averages, memory/swap usage, disk space (with inode check), failed systemd services, and listening port count. Returns clear HEALTHY/ISSUES DETECTED status with specific warnings and thresholds. This is the go-to tool for a quick 'is everything OK?' check. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct subsystem or concern: systemd services, processes, disk, memory, ports, cron, nginx, Docker, and overall health. Even service_status and system_health are clearly separated by scope, with the former for a single service and the latter for aggregate system checks.
All tool names follow the same snake_case resource-oriented pattern with two segments describing the target and the data/action (e.g., service_status, disk_usage, port_scan). No mixed naming conventions or vague verb-only names appear.
Ten tools is a well-scoped size for a DevOps dashboard server. Each tool covers a meaningful monitoring area without unnecessary duplication or excessive fragmentation, and the count feels natural for the domain.
The tool surface covers most core server monitoring needs: services, logs, processes, disk, memory, ports, cron, nginx, Docker, and an aggregate health check. Minor gaps exist, such as no dedicated Docker logs or network throughput tool, but agents can still perform common diagnostic workflows.