mcp-systemctl
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 |
|---|---|
| list_servicesB | List all systemd services. Optionally filter by state (running, exited, failed, inactive, all) and by name glob pattern (e.g. 'ssh*', 'cron*'). Defaults to listing all service units. |
| get_service_statusA | Get detailed status of a specific systemd service. Returns load state, active state, main PID, memory, CPU, tasks, documentation, and uptime. Accepts service names with or without the .service suffix. |
| list_failed_servicesA | List all systemd services that are currently in a failed/error state. Returns unit name, load state, active state, sub state, and description for each failed service. |
| get_service_logsA | Retrieve recent journald log entries for a specific systemd service. Supports configurable line count (up to 5000) and optional priority filtering (emerg, alert, crit, err, warning, notice, info, debug). |
| service_controlA | Control a systemd service: start, stop, restart, reload, enable, or disable. NOTE: Most actions require root/sudo privileges and will return a permission error if unavailable. |
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 5 tools
Each tool targets a distinct aspect of systemd service management: listing all services, listing failed ones, getting detailed status, retrieving logs, and performing control actions. No overlap in purpose.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_service_logs, list_services, service_control). The naming is predictable and clear.
5 tools is an appropriate number for managing systemd services. It covers the essential operations without being overly granular or sparse.
The set covers all common tasks: listing with filters, checking status, retrieving logs, controlling services (start/stop/enable/disable), and listing failed services. No obvious gaps for typical systemctl usage.