system-monitor
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_system_statusA | Get comprehensive system status for production server monitoring. Covers performance metrics, hardware specs, software environment, storage & disk I/O, network traffic & connections, running processes, systemd services, Docker containers, CPU/GPU temperatures, logged-in users, security posture (open ports), displays, battery, and peripherals. Use 'overview' for a quick health snapshot, or specify a category for deep details. |
| discover_configsA | Scan the system for known service configuration files (nginx, mysql, redis, docker, sshd, etc.), or scan a specific directory for project-level config files (like .env, .npmrc, *.json). Returns a list of detected config files with their paths, sizes, and last modified times. |
| read_configA | Read and parse a specific service configuration file. Supports JSON, YAML, INI, TOML, env, nginx conf, sshd_config, sysctl, crontab, hosts, fstab, resolv.conf, and more. You can specify either a service name (e.g. 'nginx') to auto-locate the config, or provide a direct file path for custom configs. |
| read_logA | Safely read the end of a log file (tail), optionally filtering by a keyword (grep). Extremely efficient for huge log files as it reads backwards from the end without loading the whole file into memory. Use this instead of read_config for files like /var/log/syslog, nginx access logs, or any file that could be massive. |
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 4 tools
The four tools are mostly distinct: status monitoring, config discovery, config reading, and log reading. However, read_config and read_log could cause confusion (both deal with reading files), and discover_configs could be seen as overlapping with read_config since both touch config files. The descriptions clarify boundaries well, but the similar purposes create minor ambiguity.
Tools follow a mostly consistent verb_noun pattern (get_system_status, discover_configs, read_config, read_log). All use snake_case with imperative verbs. The inconsistency is that get_system_status uses a 3-word name while others use 2-word names, and 'discover' vs 'read' vs 'get' are slightly different verb styles for similar actions.
Four tools is on the lower end but reasonable for a focused system-monitoring server. It covers status, config discovery, config reading, and log reading - a coherent but slightly thin set. One or two more tools (e.g., executing commands, managing services) could round out the surface.
The server covers monitoring (status), config exploration (discover/read configs), and log inspection (read_log). However, it lacks write-capabilities entirely - there's no way to modify configs, restart services, or send commands, which feels like a notable gap for a system-monitor. Additionally, there's no tool for managing processes or services beyond reading, only observing them.